Automated quality control assessments of datasets associated with real estate transactions

ABSTRACT

A computer-based system assesses whether documents are accurate and sufficient to support various transactions. In one aspect, a document manifest is provided in connection with quality control results and corresponding reports. The document manifest lists documents that are required for a particular transaction. The list may also be associated with document publication pursuant to the transaction. The document publication aspect allows dataset quality control procedures to be associated with documents published for a transaction. This aspect also allows confirmation that the appropriate version of the published set of documents is or was used for the transaction.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.10/989,559, filed Nov. 17, 2004, entitled “Document Manifest andPublication in Association with Dataset Quality Control,” which is acontinuation-in-part of U.S. application Ser. No. 10/405,890, entitled“Electronic Mortgage Quality Control” and filed on Apr. 1, 2003, whichis a continuation-in-part of U.S. application Ser. No. 10,326,570, filedDec. 20, 2002 and entitled “Certification for Expedited Mortgage Sales,”which claims the benefit of U.S. Provisional Application No. 60/369,030,filed Apr. 1, 2002 and entitled “System, Specification & Tools forCreating Processing, and Validating Electronic Documents”. The entirecontents of these applications are hereby incorporated by reference.

BACKGROUND

1. Field of the Invention

This invention relates generally to data processing, and moreparticularly to a manifest and publication functionality applied inconjunction with the review of electronic datasets.

2. Description of the Related Art

Borrowers often use lenders to finance real estate transactions in theprimary mortgage market. A mortgage loan closing may involve a propertysale, or a refinancing of an owned property. Where there is a propertysale, a typical mortgage loan closing can involve a buyer, seller, andlender. The lender loans funds to the buyer, and disburses them to theseller to complete the transaction. The buyer signs a promissory note(also referred to as a mortgage note) that obligates the buyer to repaythe loaned funds. The buyer is thus often referred to as the borrower inthe mortgage loan closing transaction.

Lenders sell mortgages to investors in what is known as the secondarymortgage market. Examples of investors include government sponsoredentities (GSEs) such as Fannie Mae, Freddie Mac, and Ginnie Mae.Investors also include commercial banks, community banks, savings andloan associations, and others. Some of these entities participate asboth lenders and investors at various times. That is, they both sell andpurchase portfolios of mortgages. Similar mortgages are also oftenpooled together and used to as security for investment instrumentsreferred to as mortgage-backed securities.

A problem with the sale of loans in a secondary market is the lag timebetween the original acquisition of the mortgage by the lender (e.g., atthe closing) and the sale of the mortgage to the investor.

Electronic documents are being introduced for mortgage transactions. Useof these documents can be beneficial to participants in such marketsbecause they can reduce the amount of physical error checking that isoften required for paper documents, as well as the number ofopportunities for creating discrepancies and errors among and betweenthe various forms used by different participants. However, even where alender uses electronic documents, a typical closing will still oftenimplement traditional paper based practices, wherein borrowers signstandard paper forms using pen and ink (also referred to as “wet”signing in the industry). Where such a mortgage is later sold to asecondary market investor, since traditional paper forms are used,traditional delays in providing funds to lenders pursuant to themortgage purchase by the investor have remained.

Another problem with transactions in the secondary mortgage (and other)markets is that investors often have complicated requirements forpurchasing loans. Lenders often use experienced analysts to try toensure that loans will meet these complicated requirements before theyagree to lend the money to the borrower. Sometimes, analysts makemistakes and loans are later found not to be marketable to the investor.The loan then likely becomes what is referred to as a “scratch & dent”loan that is sold at substantially discounted rates as compared to whatthe lender would have gotten from the investor. Moreover, a loan may besubject to repurchase obligations if the investor finds it to bedeficient after purchase. There the lender would have to repurchase theloan, and then market it as a scratch & dent loan, incurring losses fromthe sale of the loan as well as additional marketing expenses.

Another problem with electronic documents is that there are variousdifferent systems to which a document will need to integrate. Even whereall of the parties to a transaction, and parties to related transactionsuse the same electronic document format, there are still oftendiscrepancies among and between the variously defined documents.

Still another problem with electronic documents relates to determinationof the appropriate documents to be used for a particular transaction,and assurance that the transaction and related transactions implementthe correct version of such documents. With real estate closingtransactions, a wide variety of documents may be required for inclusionin a proper closing package, depending upon factors such as the type ofloan product and the governing State. Even where traditional paperclosings are implemented, the determination of the elements in a closingpackage is often made ad hoc, based upon the experience of the closingagent or other party. Some document origination systems include afacility for printing documents, and thus at some point may provide alist of documents to be printed pursuant to a transaction. However, suchlists are not designed for recovery after the transaction takes place,and are also not designed for post-printing association with the printeddocuments.

What is needed is a quality control system that overcomes the problemsof conventional systems.

SUMMARY

The present invention includes aspects that provide greaterpredictability in terms of marketability of electronic documentsfollowing anticipated transactions, accommodate consistency among thevarious documents connected to a given transaction, and expedite salesof mortgage loans involving electronic mortgage documents even wheretraditional pen and ink signing is used pursuant to closings.

The present invention may be provided in the context of an electronicmortgage document quality control system. For example, a quality controlprocess may be applied to electronic mortgage documents corresponding toloans that are candidates for sale on the secondary mortgage market. Aquality control system manages numerous potential rule sets. A rule setparticular to a transaction type includes rules that, when satisfied,verify that the electronic mortgage document is appropriate for thetransaction type. A lender can thus, for example, subject a candidateelectronic mortgage document to the quality control process and receiveconfirmation that the corresponding loan can subsequently be sold to aninvestor prior to originating the loan.

The rules also allow the generation of reports that are tailored topotential problems with electronic mortgage documents. This allows thelender to correct errors or omissions, and thus modify the electronicmortgage document so that it will be known to be marketable. Althoughone embodiment of this process applies to secondary mortgage markettransactions, it is also applicable to transactions other than sales onthe secondary mortgage market.

According to one aspect of the present invention, a document manifest isprovided in connection with quality control results and correspondingreports. The document manifest lists documents that are related to (and,depending upon the party, required for) a particular transaction, suchas a real estate closing. The list may also be provided in associationwith a document publication feature that is provided according toanother aspect of the present invention. The document publication aspectallows assurance that quality control procedures are applied to theelectronic mortgage dataset used to produce documents that are publishedfor a transaction (e.g., a closing). This aspect allows a party (e.g.,closing agent) to ensure proper publication of documents, and partiesengaging in post-closing activities to do the same.

The document manifest aspect of the present invention may be provided asa computer-implemented method that involves accessing an electronicmortgage dataset corresponding to a request for a computer implementedquality control check in connection with a particular real estatetransaction; identifying a plurality of documents that are required forthe particular real estate transaction in association with the request;verifying that the electronic mortgage dataset is sufficient toaccurately provide the plurality of documents; and providing a list ofthe plurality of documents that is verifiably connected to theelectronic mortgage dataset, whereby correct versions of the pluralityof documents may be published pursuant to a completion of the particularreal estate transaction and independently obtained for additional realestate transactions that follow the particular real estate transaction.It may alternatively be provided as software, computer program products,systems, and the like that provide such a functionality.

As indicated, the document publication process is provided in connectionwith the quality control. A publication value such as “Printed” isassociated with electronic mortgage datasets to indicate whether acorresponding package of documents has been readied (e.g., qualitycontrol checked and printed) for a transaction such as a closing. Thepublication process also may incorporate versioning. When a givenpackage of documents is published, it is preferably versionedincrementally. Additionally, each document that is printed pursuant topublication includes some kind of indication of the package versionnumber. This allows the documents in the package to be collectivelymanaged, while also ensuring accuracy and integrity of the underlyingdata.

The present invention can be embodied in various forms, includingcomputer implemented methods, computer program products, computersystems and networks, user interfaces, application programminginterfaces, and the like.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other more detailed and specific features of the presentinvention are more fully disclosed in the following specification,reference being had to the accompanying drawings, in which:

FIGS. 1A-B are event diagrams illustrating an embodiment of qualitycontrol;

FIGS. 2A-B are event diagrams illustrating an embodiment of qualitycontrol procedures in support of the expedited sale of mortgage loans;

FIG. 3 is a block diagram illustrating an example of an electronicdocument architecture.

FIGS. 4A-B are schematic diagrams illustrating examples of systems inwhich EQC systems and corresponding functionality is provided.

FIG. 5 is a block diagram illustrating an embodiment of an EQC system.

FIGS. 6A-B illustrate an example of a format for an electronic document.

FIG. 7 is a schematic diagram illustrating an application of EQCprocesses and corresponding transactions.

FIG. 8 is a display diagram illustrating an example of an EQC resultsreport.

FIGS. 9A-B are display diagrams illustrating another example of an EQCresults report that includes a document manifest.

FIG. 10 is a schematic and flow diagram illustrating an embodiment of aprocess for publishing document sets for real property transactions.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerousdetails are set forth, such as flowcharts and system configurations, inorder to provide an understanding of one or more embodiments of thepresent invention. However, it is and will be apparent to one skilled inthe art that these specific details are not required in order topractice the present invention.

FIGS. 1A-B are event diagrams illustrating an embodiment of anelectronic mortgage quality control (“EQC”) based transaction 100. Theillustrated participants in the transaction 100 include a lender,closing agent, EQC system provider, and investor.

Although participants are shown separately, at times the roles ofmultiple participants may merge. For example, the investor may provide amortgage services platform, and within that context provide EQCfunctions that can be referred to as an EQC system.

The EQC system variously offers business predictability to participants.Features provided by the EQC system include determinations whetherelectronic data sets are sufficient to support a particular transaction,and whether data sets of multiple parties participating in a giventransaction are consistent and accurate. Although the EQC system isapplicable to any transaction, for ease of description it is detailed inconnection with the sale of a mortgage loan from a lender to an investorin the secondary mortgage market. In that regard, the EQC systemincludes rules that are used to determine whether electronic datacorresponding to the loan is accurate includes the necessary elements tosupport such a transaction.

The rules provided by the EQC system can be thought of as falling withinmultiple categories. The first can be referred to as a “core set” thatis required to generally support a given transaction. For example,industry standards that govern the sale of loans from any lender to anyinvestor in the secondary mortgage market dictate the constitution of acore set of rules for that type of transaction. The additionalcategories are respectively party driven. For example, a particularinvestor may contribute rules beyond the industry standard, and aparticular lender may have an even more stringent review process thanthe investor, and thus desire still further rules. The EQC system isarranged to variously accommodate rule contributions. For example, theEQC system may include the core set of rules by default, and includemechanisms for allowing participants to submit additional rules.

An agreement 102 between the lender and the investor, wherein theinvestor promises to buy EQC compliant mortgage loans from the lender inexchange for the lender's successfully invoking the EQC system, allowsthe sale of such mortgage loans without requiring the lender to makecertain representations and warranties concerning the marketability ofparticular loan products in the secondary mortgage market. Successfullyinvoking the EQC system refers to submitting the electronic mortgagedata set to be used for the loan, and receiving a “pass” indicationregarding that data. A pass indication means that the data has satisfiedall of the conditions found in the rules applied to the data by the EQCsystem. Where all of those conditions are satisfied, it can be said thatthe EQC system produces no “findings” based upon application of thoserules. Preferably, the waived representations and warranties includethose pertaining to whether the mortgage loan (i.e., the promissorynote) sold by the lender to the investor is a legally enforceable asset.This allows the lender to avoid repurchase obligations should the loanbe to be found deficient after the secondary market sale. Although thisrepresentation will be waived, the lender will still be required to makeother representations, such as those involving appraisal of the propertyand credit worthiness of the borrower.

The agreement aspect is optional. Even if the agreement is notimplemented, the lender can implement the EQC system to assist in thepreparation of loan packages that include all necessary components formarketability. Initially, the lender creates 104 the loan package,usually based upon interactions with a borrower who is either purchasingor refinancing a property. The lender often uses a loan originatingsystem (LOS) to prepare the package. The closing package for a loanincludes a note, a security instrument, RESPA required documents, andother documents.

Lenders have various systems for generating loan packages, some of whichdo not implement their own LOS. For example, the lender may originate amortgage and create the necessary documents in conjunction with aservice provider's electronic mortgage system, such as the MORNETPlus®2000 system, which implements Desktop Underwriter®, Desktop Originator®,and MORNETPlus Connections, all provided by Fannie Mae. In particular,the Desktop Underwriter® works with various conventional LOS systems toallow lenders to originate mortgages and create documents such as loanapplications. Other pertinent documents can also be created byindependently using an LOS, or through MORNETPlus Connections. There arevarious alternatives, including but not limited to those working withthe Freddie Mac Loan Prospector®, third party document preparationsoftware, and others. Preparation of the loan package results in thecreation of an electronic mortgage data set (“EMD”). The EMD may bevariously embodied. For example, the EMD may be a lender dataset that isapplicable to the loan package, and is used to create correspondingdocuments. The EMD may also be provided as an Extensible Markup Language(XML) based file containing previously defined elements and attributes,and corresponding values.

In another alternative, the EMD may be a formal electronic mortgagedocument. Although aspects of the present invention are applicable toany data set, an example of a format for a formal electronic mortgagedocument is described further below, with reference to FIGS. 3 and 6A-B.Additionally, regardless of how it is embodied, the EMD may later berepresented in paper form where the EMD is used to create paperdocuments, if applicable.

Preferably, the EQC request and EMD are sent together to the EQC system,for application of the request to the EMD. There, the EQC request andEMD can be commonly transmitted but separately packaged. Alternatively,particularly where a formal document definition is applied, the EQCrequest and the EMD can be packaged together. In another alternative,the EMD may already reside with the EQC system, or be provided byanother party (e.g., a closing agent), with the EQC request beingindependently provided to the system.

With the EQC request functionality, lenders (or others, e.g., closingagents, title cos., appraisers, etc.) send their data to the EQC system,where the EQC rules are applied to the data, and corresponding resultsfile is returned to the requestor.

The EQC system maintains rules to be applied to EMDs in a database. Eachloan product will preferably have a rule set tailored to the product.For example, an investor has requirements for a particular loan productthat are reflected in the rule set for that loan product. These rulesvary in complexity, from those that merely ensure the presence ofpredetermined fields in the EMD, to those having more complicated logic.Detailed examples of rule sets are described in connection with FIG. 5,below.

After receipt of the EQC request, the EQC System runs 110 an EQC Requestfunctionality against the submitted EMD. For loan products, this entailsidentifying the product, retrieving the appropriate rule set for theloan product from its rules database, and applying the rules to the loanproduct. Preliminary validation, such as XML validation against a DTDfor the EMD, may also be applied prior to application of the rules, asdescribed further below. The format of the EQC request will vary, but anexample of an EQC format is described further below.

The EQC System then generates 112 results corresponding to the request.Preferably, the results are recorded in the form of a report. The EQCresults can be variously provided to one or more recipients. Threeexample modes include asynchronous, synchronous, and postback. In theasynchronous mode, the results are retained by the EQC system and areassociated with a report identifier (e.g., a GUID). The reportidentifier is later used to retrieve the EQC results. For example, thelender may provide the identifier to the investor, who may then use theidentifier to make their own EQC request, which returns the sameresults. In the synchronous mode, the EQC results are returned inassociation with the EQC request. In the postback mode, the EQC resultsare simply posted to a web server corresponding to an URL submitted withthe request. FIG. 1A illustrates a potential application of asynchronous mode wherein the lender receives 114 EQC resultscorresponding to its submitted 106 EQC request.

FIG. 8 is a display diagram illustrating an example of an EQC resultsreport 800. The report 800 includes an Analysis Summary Informationsection 802, an EMD Summary section 804, a Loan Characteristics section806, and a Findings section 808. The Analysis Summary Informationsection 802 contains basic information to identify the underlying loan,identify the date and time that the EQC request was run (e.g., todistinguish the report from other EQC reports for the same loan and/orEMDs), and whether any issues were found in the particular EQC run.

The EMD summary section 804 identifies the EMDs to which the EQC requestand report apply. Preferably, each EMD submitted to the EQC system isassociated with a uniquely identified so that the data can later becorrelated to EQC results. An example for such an identifier is adate/time stamp for the EMD. The date/time stamp can variouslyoriginate. Where the EMD is a data set coming from an LOS or other partysystem, the date/time can correlate to a time when a corresponding fileis entered into the system. Where the EMD is XML data, a time stampcorrelating to the file containing the XML data can have the date/timestamp. Alternatively, an element or attribute in the XML data can definea value (such as date/time) that is used to identify such an EMD. Wherethe EMD is a formal electronic document, a field in the electronicdocument (which itself may be an XML element or attribute) can containthe date/time stamp value. Still further, an EMD (formal or informal)can be a file containing a time/date stamp, to which a tamper-evidentseal is applied. A “seal” wrapping an electronic document that iscreated by a digital signature. The seal can be verified to ensure thatno changes have been made to the EMD since the seal was put in place.

The Loan Characteristics section 806 contains information that providesfurther information about the loan, preferably a basic overview ofcharacteristics that are believed to be of value to the reader of thereport. Finally, the Findings section 808 contains details about issuesthat are found by application of the relevant rules to the subject EMD.If no issues are found, this may merely indicate “no issues”, or “EQCpass”, or “no findings” or any other indication of those type ofresults.

As indicated, the EQC results in this example pertain to the followingEMDs: LOS data, Closing Agent (CA) Data, and an electronic closingdocument. Accordingly, the illustrated Findings section 808 includesLender Data Set Issues, Lender Data Set Comparison Issues, Closing AgentData Set Issues and Lender/Closing Agent Data Set Comparison Issues. The“comparison” issues pertain to consistency of data among various sources(e.g., closing document to EMD, or EMD to EMD). The remaining issuespertain to rules that examine EMDs for the presence of certaininformation. More examples of rules are described further in the tablesbelow.

FIGS. 9A-B are display diagrams illustrating another example of an EQCresults report 900 a-b that includes a document manifest. This exampleof an EQC results report 900 a-b may be used in connection with thedocument publication process of the present invention. The report 900a-b includes an Analysis Summary Information section 902, an EMD Summarysection 904, a Loan Characteristics section 906, a Findings section 908a-b, an Issues Summary section 910, and a Document Manifest Section 912.

The Analysis Summary Information section 902, EMD Summary section 904,Loan Characteristics section 906 and Findings section 908 a-brespectively include the same information as was described for thecommonly named sections (802-808) in the example of FIG. 8.

This EQC results report 900 a-b adds the Issues Summary section 910 andthe Document Manifest section 912. The Issues Summary section 910includes a general description of the issues that were discovered inconnection with the processing of an EQC request corresponding to anelectronic mortgage dataset. In addition to corresponding to theparticular entries found in the Findings section, 908 a-b, thisparticular example of the Issues Summary section 910 includes entriesrelevant to the information in the Document Manifest section 912, aswell as the document publication process that is described furtherbelow. Generally, the EQC process that implements the documentpublication in accordance with the present invention ensures that theclosing documents that are published in connection with a closing arebased upon a dataset that is current, consistent with other relevantdatasets, and reviewed for error.

The Issues Summary section 910 allows the user to quickly review thecategories of issues found without requiring review of the detailedinformation found in the Findings section 908 a-b. The Issues Summarysection 910 is generally organized according to the categorization ofthe underlying rule sets that are used to check submissions and generateEQC results as described further below.

The five categories that are preferably implemented in embodiments usingthe document publication feature are as follows.

The first category of issues is comparison of lender and closing agentdata. When these issues exist, the following text will appear in theIssues Summary section 910: “1. Data used to populate the Lender'sprinted documents differs from the data used to populate the ClosingAgent's printed documents.”

The second category of issues is errors in the lender's data set. Whenthese issues exist, the following text will appear in the Issues Summarysection 910: “2. Data contained in the Lender's Loan Origination Systemcontained errors.”

The third category of issues is differences between a lender's systemand printed documents data sets. When these issues exist, the followingtext will appear in the Issues Summary section 910: “3. Data used topopulate Lender's printed documents differs from the most current datain the Lender's Loan Origination System.

The forth category of issues is errors in the closing agent's data set.When these issues exist, the following text will appear in the IssuesSummary section 910: “4. Data used to populate the Closing Agent'sprinted documents contained errors.”

Finally, the fifth category of issues is differences between a closingagent's system and printed documents data sets. When these issues exist,the following text will appear in the Issues Summary section 910: “5.Data used to populate Closing Agent's printed documents differs from themost current data in the Closing Agent's System.”

The Document Manifest section 912 includes a listing of those documentsthat should be included as part of the final closing package used by theClosing Agent. The listing may be used by the Closing Agent to ensurethat all of the correct documents are published pursuant to a closing.

The Document Manifest section 912 may also be used by any party engagingin a post-closing activity that relates to the closing, to eitherconfirm that all of the correct documents were published for theclosing, or to ensure that the correct documents are being used for therelevant post-closing activity. The related transaction may, forexample, be taking custody of, recording, reviewing, or engaging in anyprocess related to one or more of the documents in the closing package.In any event, the connection to the EQC results allows confirmation ofthe adequacy and accuracy of the data contained in the documents.

Preferably, the Document Manifest section 912 provides a listing of thedocuments corresponding to the closing package, such as the rows in thetable in EQC results report 900 b. Columns corresponding to the documentname, document version, date/time, # of pages, borrower signaturerequired, file name, and comments may also be provided. The documentversion field is described further in connection with the documentpublication aspect of the present invention below. Preferably, the“document version” in this field corresponds to a version number that istied to publication of the documents in the closing package. In thatinstance the column could also be called “publication version” ifdesired. The version number is also preferably represented in theindicator that is provided on displayable (e.g., printed) versions ofthe published documents, which helps users to ensure that printeddocuments correspond to the document manifest and thereby the appliedquality control processes.

The document manifest may be provided as desired by the parties in atransaction. Alternative examples of the document manifest may containmore, fewer, or different entries from those in the illustrated example.

The remaining information in the Document Manifest section 912 is usefulfor ensuring that all of the pages of a document are present, that theproper number of copies are provided, and other information useful forlocating and identifying corresponding files, as well as the date/timestamp corresponding to the published version.

Regardless of the mode and content, the report can be put in variousformats. However, one preferred report uses a formal electronic documentformat. As described further below, this type of document includes maindata and view sections, with the main data section containing resultsinformation, and the view section containing presentation formatting forrendering the printed or viewed report (e.g., FIG. 8). A header sectioncontaining fields identifying the document as an EQC results document,and other criteria, is also included.

With the provision of the EQC results, the lender (or other party) hasimmediately verifiable indication of compliance with the rule set(s)corresponding to the EQC request, or indication of what needs to be doneto gain compliance. This, for example, allows a particular lender torevise an EMD so that it complies with the expectations of a particularinvestor, prior to closing the loan. The lender can remedy the faultsidentified in the report and then resubmit the modified package to againseek an indication that the loan will be transferable. These featuresafford a level of business predictability that is completely absent fromconventional systems.

Once the lender has submitted an EQC request and is satisfied with thereport (and has verified completion of any other necessarypreconditions, such as appraisal and title search), the lender sends 116the closing package to the closing agent in preparation for the closing.The closing package can be sent using conventional mechanisms, includingbut not limited to regular postal service, express mail services,electronic mail, electronic data transfer, or other any other form ofcommunication.

The closing 118 is also a conventional paper or electronic closing. Inthe paper closing, the closing agent obtains closing documents byreceiving them in paper form from the lender, or by printing them basedon a formal electronic document or other data set, or through othermeans. In the electronic version, the relevant parties electronicallysign the corresponding electronic mortgage documents. The closing iscompleted by having the documents reviewed and executed by relevantparties, such as the borrowers. The executed documents include, amongothers, the mortgage note. At this (or some prior) time, the closingagent may wish to check the closing agent data set for the closing toensure that it is consistent with the actual closing data in the closingpackage, and to apply any additional closing agent specific rules to thesame.

Once all of the loan documents are executed, they are sent 120 to lenderand/or the investor, again using conventional means for sending paper orelectronic documents. The electronic closing package may be variouslyembodied. For example, a single “electronic document” containing viewscorresponding to the different paper documents could be provided, or anarchive file format, such as a conventional Java™ JAR file, or a ZIPfile could contain multiple electronic documents respectivelycorresponding to the different required documents can be provided.

As indicated in FIG. 1B, at some point the lender offers 122 the loan tothe investor. Although this process is shown to occur after the closing,it may also occur before the closing. Various conventional formats andprotocols for offering to sell the loan to the investor may be used,such as Funding Express® and/or MORENET as provided by Fannie Mae. Thelender and the loan have pertinent data that are used to connect thesending of funds to a lender pursuant to a particular purchase.

Although sending 124 the EQC results is shown to occur after theclosing, the investor may be variously made aware of the EQC results. Asdescribed, the EQC results can be posted to the investor when the EQCrequest is made by the lender prior to the closing. Alternatively, areport retained by the lender can be sent to the investor, or theinvestor may independently make an EQC request and thereby receive theresults. Still further, the report may actually be sent to otherparties, such as a third party reviewer of the results.

After conventional review processes (or the certification processdescribed in connection with FIGS. 2A-B), the purchase proceeds are sent126 to the lender. Sending purchase proceeds, also referred to as therelease of funds to the lender for the loan purchase, can useestablished funding protocols. Funding options include processes thatprovide the lender with early payment for a loan to be sold to aninvestor. Funds are typically sent to the lender in advance of poolingor pool settlement date (and a fee charged to the lender), subject toestablished credit limits. Once the lender determines the finaldisposition of the loan (e.g., to be sold as Cash or MBS—tied to aspecific commitment/forward sale) the loan is delivered 128 to theinvestor—at which point the investor will “settle up”—any additionalmonies due from the lender based on the early funding plus the feecomponent. Alternatively, with a direct sale, documents are typicallyreceived and validated by either investor's custodial function or a 3rdparty custodian. There is no “settle up” period because the price anddelivery has already been established.

FIGS. 2A-B are event diagrams illustrating an embodiment of qualitycontrol procedures in support of the expedited sale of mortgage loans.Here, the features of predictability, data integrity verification, andefficiency described above in connection with the EQC System areintegrated with a conventional closing involving pen and ink signing ofpaper closing documents, for expedited funding pursuant to the purchaseof loans by an investor. This is accomplished by running an EQC requeston a formal electronic document, and providing EQC results that areevident both in relation to the electronic document and the printedversions of documents created from the electronic document. In oneembodiment, the electronic document is updated to reflect the EQCresults, and this update will include information that causes thecorresponding printed documents to contain a unique mark thatcorresponds to the EQC results. This allows parties to later rely uponthe EQC results for integrity and completeness of the data in theelectronic document, as described above, and to rely upon the uniquemark on the executed, printed document actually used in the closing toverifiably associate the document to the EQC results. For example, aninvestor may receive the EQC results and the electronic document for aloan, identify the executed paper documents from the closing asassociated with those EQC results and electronic document, and rely onthe same in releasing funds pursuant to a purchase of the loan.

Referring to FIG. 2A, after the front-end procedures of creatingelectronic loan documents, an EQC request is made. Here, in addition toproviding an EQC results report, the electronic documents are updated toreflect the same. Preferably, part of this update is modifying theelectronic document to cause the electronic document to produce aprinted document having a unique mark corresponding to the EQC result.One preferred marking is the previously described date/time stamp.Alternative markings, such as a uniquely created identifier that isgenerated by the EQC system and applied to the EMD that is later used tocreate prints, can also be used. Again, this may be an iterative processwherein the lender remedies any errors found during each EQC request,with the electronic document being modified upon receipt of asatisfactory result. Under those conditions, each iteration wouldinclude a new date/time stamp.

An electronic closing package that has been reviewed and updatedaccording to this process may be referred to as an EQC compliantelectronic closing package. The lender sends 202 the closing package tothe closing agent prior to the closing, and after any other necessaryconditions (e.g., title search, appraisal, etc.) are completed.

The closing agent then prints 204 the necessary documents for theclosing using the information in the electronic closing package.Alternatively, the lender may have done the same, and thus will havesent the materials to the closing agent already in paper form.Regardless, all necessary documents, such as the note, will contain amark connecting the printed document to the EQC compliant electronicclosing package. The mark may be evidenced anywhere on the documents,such as in the footer.

The closing agent then conducts a conventional closing 206, wherein thedocuments are reviewed and executed by relevant parties, such as theborrowers. As indicated, the executed documents include the note.

The executed closing documents and the electronic closing package aresent 208 to a certifying agent. The certifying agent then verifies thatthe executed documents correspond to the electronic closing package, andperforms additional certifications, as follows. First, the certifyingagent checks 210 the EQC status of the electronic closing package.Preferably, this includes referring to the EQC results alreadyassociated with the electronic closing package. The certifying agentalso determines whether the executed paper corresponds to the electronicclosing package and the EQC results by verifying that the paper containsthe unique mark. Checking 210 the EQC status may also include makinganother post closing EQC request, although others such as the investormay alternatively perform this task.

Once it has been verified that the electronic closing package, thesigned paper document, and the EQC results are all commonly connected,that certifying agent checks 212 the executed closing package in orderto make additional certifications. The certifying agent then issues 214a certificate that represents that the executed note corresponds to theEQC results, in addition to one or more of the followingrepresentations: that the printed documents were signed properlypursuant to the closing; that funds were properly disbursed (typicallyto the borrower); and that a particular note format was used (e.g., forthe State or product). The certificate may also be issued in relation toa contract among the lender, investor and certifying agent, or,alternatively, an electronic surety policy covering the above-describedrepresentations and warranties, with the investor being designated as abeneficiary the policy along with the lender. The certificate may bevariously sent to the investor (and the lender) such as by e-mailing anAdobe Acrobat® PDF file.

The electronic closing package is also sent to the investor. This allowsthe investor to run a post closing EQC check, if desired. The investorcan also review the certificate and perform any additional in-house datacomparisons prior to sending 218 funds to the lender pursuant to itspurchase of the loan. The sequences for offering 216, funding 218, andreceiving 220 the loan are described above in connection with FIGS.1A-B. The investor relies on the certificate to provide funds to thelender without traditional delays involved in selling mortgages in thesecondary market. Normally, the investor would not immediately sendfunds to a lender pursuant to the purchase of a loan, without additionalsteps such as the review of the executed closing documents by a titlecompany or other third party, and provision of correspondingrepresentations and warranties by the lender. By contrast, EQC systemparticipation allows the lender and investor to proceed with the salewithout such representations and warranties, and allows them to do sowithout requiring traditional document review to ensure the completenessand correctness of the loan data in the closing documents.

Before moving to further description of the operations of the EQCsystem, it is helpful to review an example of an electronic documentformat. FIG. 3 is a block diagram illustrating components of anelectronic document usable in conjunction with embodiments of qualitycontrol in accordance with the present invention, although various otherelectronic document types and formats may also be used. The electronicdocument 300 includes a header section 310, a data section 320, and aview section 330. The electronic document 300 may also include asignature section 340 as part of its format; however, the signaturesection might not be used where paper closing documents are used, or thesignature section 340 may merely indicate that paper documents were usedand signed, in lieu of maintaining an electronic signature.

The electronic document 300 is preferably defined using a mark-uplanguage. The electronic document 300 may be structurally altereddepending upon the processing environment. For example, it may becomedesirable to strip one or more of header 310, data 320, view 330 andsignature 340 sections from the electronic document 300 to facilitateprocessing, display, transmission, or for intended use. Particularly, anelectronic document that is only intended for machine processing may attimes only include the header and data sections 310, 320, or anelectronic document that is only intended for viewing may not contain adata section 320 (e.g., a billing statement emailed to a client).

The header section 310 contains information about the document itself,such as its version, the type of document (e.g., that the document is amortgage note, trial transcript, etc.) and whether or not all partieshave signed. The data section 320 contains the information correspondingto that originating from an equivalent paper document, such as data froma mortgage note. The view section 330 contains tags that describe how toformat and present the data contained in the document. For example, theview section 330 contains tags that describe how to format and present aprinted mortgage note.

The header and data sections 310, 320 are preferably written inextensible markup language (XML) and the view section 330 is preferablywritten in extensible hypertext markup language (XHTML), which areconventional languages for creating electronic documents, althoughvarious alternative languages may be utilized. The names of the tags andthe structure of XML documents are defined by a document type definition(DTD). The DTD associated with a particular electronic documentdescribes the tags or markup and the structure of the document, andspecifies which tags contain other tags. Conventional XML and XHTMLprogramming techniques can be used to create the tags particular tocontent and format required by industry standards or the like.

The data section 320 can be organized using elements as well. Forexample, it may be generally demarcated by a “DATA” element that issubdivided into MAIN and MAP elements, with the MAIN element containingthe XML structural description of the data model for the particularelectronic mortgage document. For example, the MAIN element mightincorporate LOAN (the terms and features of the loan, e.g., the interestrate and loan amount), BORROWER (information about the borrower), LENDER(information about the lender), PROPERTY (information about the propertywhich is the subject of the mortgage), and EXECUTION (information aboutthe date and location of the execution of the note) elements.

The MAP element generally links fields in the data section 320 topresentation fields in the view section 330. An electronic document mayinclude more than one “view,” so there may be a MAP element for eachview that a DATA element is linked to. For example, if an electronicdocument contained three different view sections representing the datafrom a single data section, there would be three corresponding MAPelements within the DATA element.

The linking provided by the MAP element is preferably provided byelements that link values in the view section 330 to corresponding onesin the data section 320. There are various ways that a linking elementcan reference the necessary values, such as by including a pointer to afield in the data section 320 (e.g., in an attribute) and a pointer to afield in the view section 330 (e.g., in another attribute). Conversionelements may be associated with or contained by linking elements, toaccommodate differences in format between the data and view sections.

FIGS. 6A-B illustrate an example of a listing 600 for an electronicdocument structurally configured according to the architecture of FIG.3. This listing is not exhaustive, but is merely provided to illustratewhere various data would be found within a so-configured electronicdocument. The listing 600 includes a header section 620, a data section630 containing a main data section 660 and map section 670, a viewsection 640, and a signature section 650. The function of each of thesesections is described in connection with the corresponding elements ofFIG. 3. As is evident from the example MAIN section 660, fields andcorresponding values are found therein, such as the illustratedMORTGAGE_TERMS InterestRatePercent which is shown to have the value “6”.The electronic data set can be found in whole or in part in this MAINsection of the electronic document. That is, the fields andcorresponding values that comprise the electronic data set to beexamined by the EQC system are defined in this section. The view section640 is used to produce printed and displayed versions of documents.Additionally, confirmation that fields and corresponding values in themain data section 660 match those in the view section 640 can beprovided by using the ARC elements found in the MAP section 670. EachARC element contains references to the fields and corresponding values.For example, as described, the main data section 660 identifies theInterestRatePercent to have the value “6”. Similarly, the view section640 provides a value “6” for the InterestRate field. The first ARCelement found in the map section 670 associates these fields and values.During a validation of the electronic document, this ARC element is usedto verify that the main data matches the view data for the interest ratefield. As indicated, the listing provided in FIGS. 6A-B is notexhaustive, nor is this the only type of data set to which the EQCsystem functionality is applied.

Sometimes, the content of an electronic document will be influenced byindustry standards and customs. Elements in the EQC rules can be made tocomply with the elements defined by these standards and customs, so thatthe EQC system readily works with the data typically used by industryparticipants. An example of a format for an electronic document isprovided by specifications published by the Mortgage Industry StandardsMaintenance Organization (MISMO).

FIGS. 4A-B are schematic diagrams illustrating examples of computersystems 400 a, 400 b in which an EQC system operates in accordance withthe present invention. In one system 400 a, the lender 402, closingagent 404, title company 406, and investor 408 are shown. Each of theseparties 402-408 can be interconnected by a public network such as theInternet, and they can variously communicate using conventionalarchitectures and protocols, such as according to a client server modelimplementing the TCP/IP communication protocol suite, and any necessaryprotocols for transmitting, accessing, displaying, printing, andotherwise using the above described electronic documents. Alternatively,a private network, a combination or public and private networks, or anyconventional arrangement for conducting communications appropriate forthe described subject matter can interconnect the parties.

The parties also have access to a mortgage services ASP 410, whichvariously registers the different parties and allows appropriateactivities for mortgage transactions. For example, the mortgage servicesASP 410 may communicate with the lender 402 to create electronicdocuments for a closing package. This activity may be complemented bycommunications with the investor 408, who may provide assistance andinformation for loan origination and underwriting purposes. The closingagent 404 and title company 406, which may serve as the certifyingagent, also can access the electronic documents, such as through receiptof the electronic closing package, etc.

As indicated in FIG. 4B, in some systems 400 b a mortgage servicesplatform 414 may be provided by one of the parties 402-408.Particularly, the investor may provide the mortgage services platform414, which would provide services similar to the mortgage services ASP(410). In either case, the mortgage services preferably include an EQCsystem 412, 416. Additionally, each of the parties 402-408 includes anEQC module having functionality that allows EQC requests to besubmitted, and EQC results to be received and displayed. Althoughcertain systems are shown, other systems including but not limited tothose for the appraiser, mortgage insurance, hazard, floodcertification, and loan servicing agent can similarly connect to the EQCsystem.

FIG. 5 is a block diagram illustrating an embodiment of an EQC system500 that includes a registration module 502, an EQC request receivingmodule 504, an EQC rules engine 506, an EQC results module 508, and anEQC rules repository 510.

The registration module 502 accommodates conventional procedures fordetermining whether access to the EQC system 500 is appropriate, andauthenticates the party connected to the system. Various conventionalmodels may be implemented, but one preferred approach uses a usernameand password combination. The registration information and thecorresponding functionality will also likely be part of the mortgageservices platform registration. Accordingly, the username and passwordused on the mortgage services platform will carry over to the EQC system500. Registration is optional as there may be users who are not formalregistrants.

The EQC request receiving module 506 receives EQC requests. Althoughrequests from lenders and closing agents are mainly described, it isunderstood that various other types of EQC System participants may alsomake EQC requests. Examples of these participants include titlecompanies, the county recorder, custodial services, loan servicingagents, and others who would use data in the electronic mortgagedocument or rely upon the same for their participation in a transactionrelated to the loan. Additionally, a request may require connection tothe data sets used by multiple parties, such as both the lender LOS andthe closing agent system. For embodiments implementing the documentpublication functionality, the EQC request receiving module 506 receivesrequests for publication of documents usable in a real estatetransaction in conjunction with requests to check electronic mortgagedatasets.

As indicated, participant systems are configured to include EQC modulesconfigured to generate EQC requests and receive EQC results. The EQCrequest may be prepared according to the previously described electronicdocument format. For example, relating to a closing, a lender LOS EQCmodule extracts LOS data related to a closing, and packages it accordingto the electronic document format. Since the EQC request will notnecessarily entail a viewable document, this EQC request includes headerinformation identifying the data as LOS data, and the main data sectionincludes the underlying fields and corresponding values. As with theelectronic closing package, the EQC request can be embodied as a single“electronic document.” Alternatively, the EQC request can be included aspart of a file format with multiple electronic documents respectivelycorresponding to the different documents (Note, HUD-1, Appraisal, etc.)to be processed by the EQC system, along with a header identifying thepackage as an EQC request. Regardless, the header could include arequest identifier, username and password information, and instructionsfor handling the results.

Table 1 below illustrates information that is useful for an EQC Request,and certain corresponding utility functions.

TABLE 1 EQC Request/Functions CATEGORY/ATTRIBUTE FORMAT DESCRIPTIONREQUEST_GROUP Standards Format Identification String Version IDcorresponding to electronic document standard, if applicable (null ifother EMD) REQUEST RequestIdentifier Integer Number used to identify theEQC Request RequestDateTime Datetime Date time stamp of request.LoginAccountIdentifier String User ID. LoginAccountPassword StringPassword. Function_Name String Identifies the requested EQC service.REQUEST DATA _GloballyUniqueIdentifier String Globally Unique Identifier(GUID) that is returned by the system and used to retrieve the results.Used for asynchronous integrations. CONNECTION _ModeIdentifier StringIdentifies the communication model used to submit the request (e.g.,asynchronous, synchronous, postback) _PostBackURLIdentifier String TheURL of the web server where the response will be posted. Required ifModelIdentifier = Postback. MORTGAGE_PLATFORM_REQUESTSoftwareProviderAccountNumber String Identifies the account number(e.g., for the Loan Origination System or Closing Agent System).Casefileldentifier Integer Identifies the casefile ID of the loan thatthe function is being requested for. An ID will be created if one doesLenderInstitutionIdentifier Integer Institution ID that identifies thelender or branch. ClosingCompanyIdentifier String Identifies the closingcompany participating in the DATA_FILE Name String Attached eMortgagePlatform data file name VersionNumber String Identifies the version ofthe EQC request. Type String The type of attached file (e.g., “EMD”,“XML only”). FormatType String Used to determine if the attached dataset contains current _PopulatingSystemDocumentIdentifier String Used toidentify the system that has populated the data _DateTime Datetime Thedate/time stamp corresponding to the submitted

This information is shown by way of example, and many of the fields maybe omitted. The request group category of information identifies thetype of document that is being analyzed pursuant to the EQC request.Although as indicated one preferred embodiment works with regular datasets, if the EMD happens to be defined according to a particularspecification, it can be so noted. The Request and Request Datacategories contain information that is used to validate and identify theEQC request, and to similarly call up corresponding EQC results. Thisinformation includes the described user name and password. The EQCrequest receiving module 504 automatically communicates with theregistration module 502 upon receipt of an EQC request packagecontaining the username and password, without requiring userintervention to provide the information. An identifier for the EQCrequest, and a GUID used to retrieve the EQC results in particular(e.g., asynchronous) modes of operation, are also provided in thiscategory of information.

The Mortgage Platform Request category is optional and includesinformation that is used for identifying participants who are registeredwith the platform, to accommodate integration with their facilities andappropriate reporting. An identifier with previously entered loaninformation (CaseFileIdentifier) can be used to correlate the request tosuch data.

The Data_File category contains information identifying and describingthe data against which the request is processed. Optionally, where therequest is integrated with the mortgage services platform, acorresponding file name used by the platform may be provided. Theversion number for the request is used to distinguish results fromvarious requests (i.e., a data file may be subjected to several EQCrequests before and after the closing, or may have initial errors thatare corrected—the version number is used to keep track of thoseresults). The type attribute indicates the type of data that is beingprocessed. As described, the document may be a formal electronicmortgage document (EMD), regular XML data, LOS data, etc. The FormatTypeattribute indicates the actual format of the transactional document,paper or electronic. Other attributes include those that identify thesystem that populated the data file to be processed (e.g., LOSidentifier). Finally, the date/time stamp information corresponding tothe EMD is provided. In lieu of requiring a request format to includethis information, it can be automatically recognized or extracted fromsubmitted data.

The request receiving module 504 thus receives and recognizes the EQCrequests, and passes corresponding requests to the EQC rules engine 506,which in turn accesses appropriate rule sets from the EQC rulesrepository 510 and applies the rules therein to the subject data.

As indicated, there are various types of rules. Some are comparative,and ensure data consistency. Others check for the presence of requiredinformation, or perform more complicated analyses based upon existinginformation. Some rules include conditions and corresponding rulemappings. The conditions can be determined by Boolean phrases referredto as dependencies. The rule mappings typically identify fields whosevalues are examined in order to determine whether the mapping issatisfied. Error messages specific to the conditional rules describe theproblem where the mapping is not satisfied. These messages are includedin the EQC results report (e.g., FIG. 8, FIGS. 9A-B). Example rules areset forth in Table 2 below. The ordinarily skilled artisan willrecognize the alternatives, which will be dictated by the type oftransaction, corresponding industry custom and usage, and the individualneeds and desires of parties using the EQC system.

Still referring to the rules described in Table 2, examples of varioustypes of rules are evident. As is evident from the table, columns RuleID, Rule Type, Rule Name, Error Message, Dependency and Rule Mapping areprovided. The Rule ID allows an indexed organization of all rules and asshown may simply be a number. The Rule Type allows categorization ofrules (and corresponding definitions of rule sets) according to theparticipants corresponding to the EQC request. Examples of these include“Lender Intra” rules, which may be used where a lender specific EQCrequest is made, “Closing Agent Intra” rules, which may be used where aclosing agent specific EQC request is made, and “Lender/Closing AgentInter” rules, which may be used where an EQC request corresponding toboth lender and closing agent data is made. The error message columndefines the error message to be presented in the event that a rule isnot satisfied or passed. These pieces of information are used topopulate the EQC reports. The dependency column lists conditions thatare used to provide conditional dependencies that trigger application ofrule mappings. They can be thought of as part of the rule themselves, oras prerequisites for the actual rule (which would be the rule mapping).For example, with reference to Rule ID #1, where a face to faceinterview is made, a government monitoring section must be completed,even if the applicant indicates a refusal to provide the information.Thus, if the fieldLoan_Application_mterviewer_Information_ApplicationTakenMethodType hasthe value “Face to Face,” then the following rule mapping applies: thefield

-   Loan_Application_Borrower_Government_Monitoring_RaceNationalOriginType    cannot have a null value OR the field-   Loan_Application_Borrower_Government_Monitoring_RaceNationalOriginRefusalIndicator    must equal “Y”.

These and other rules, rule dependencies, and mappings are evident inthe provided table.

TABLE 2 Sample Rules Rule ID Rule Type Rule Name Error MessageDependency Conditional on INTERVIEWER INFORMATIONApplicationTakenMethodType 1 Lender The Government Government IfLOAN|_APPLICATION| Intra Monitoring section Monitoring section isINTERVIEWER_INFORMATION must be complete not complete for loanApplicationTakeMethodType = for all face-to-face whose application was‘FaceToFace’ interviews. taken face-to-face. Conditional onBalloonlndicator 2 Lender If loan is not a Maturity date not IfLOAN|_APPLICATION| Intra balloon, the correct. LOAN_PRODUCT_DATA|maturity date must LOAN_FEATURES be equal to the first Balloonlndicator= ‘N’ payment date plus less one month plus the loan term. Conditionalon LoanAmortizationType 3 Lender Life Rate Cap Life Rate Cap is IfLOAN|_APPLICATION| Intra must be present missing MORTGAGE_TERMS for ARMloans. LoanAmortizationType = “AdjustableRate” 4 Lender Margin must beMargin in missing. If LOAN|_APPLICATION| Intra present for ARMMORTGAGE_TERMS loans. LoanAmortizationType = “AdjustableRate” 5 LenderMargin must be Margin is formatted If LOAN|_APPLICATION| Intra formattedas incorrectly. MORTGAGE_TERMS xx.xxx for ARM LoanAmortizationType =loans. Margin “AdjustableRate” must also be spelled out. 6 LenderSubsequent Subsequent If LOAN|_APPLICATION| Intra adjustment capAdjustment Cap is MORTGAGE_TERMS must be present missing.LoanAmortizationType = for ARM loans. “AdjustableRate” 7 Lender IntraFirst payment First Payment If LOAN|_APPLICATION| adjustment capAdjustment Cap is MORTGAGE_TERMS must be present for missing.LoanAmortizationType = ARM loans. “AdjustableRate” 8 Lender Intra Firstpayment First Payment If LOAN|_APPLICATION| adjustment floor AdjustmentFloor is MORTGAGE_TERMS must be present for missing.LoanAmortizationType = ARM loans. “AdjustableRate” 9 Lender IntraInterest Rate Interest Rate Change If LOAN|_APPLICATION| Change Datemust Date is missing. MORTGAGE_TERMS be present for allLoanAmortizationType = ARM loans. “AdjustableRate” Conditional onLoanAmortizationType and ARM_ConversionOptionIndicator 10 Lender IntraConversion options Conversion options If LOAN|_APPLICATION| must bepresent for are missing. MORTGAGE_TERMS ARM loans that areLoanAmortizationType = convertible. “AdjustableRate” and LOAN|APPLICATION| LOAN_PRODUCT_DATA|_ARM_ConversionOptionlndicator = “Y”Conditional on LOAN_PURPOSE Type 11 Lender/ Assumption Fee AssumptionFee If LOAN|_APPLICATION Closing payee in Lender Payee does not matchLOAN_PURPOSE_Type = Agent Inter system must match in Lender and Closing“Purchase” Assumption Fee Agent system. payee in Closing Agent system.12 Lender/ Assumption Fee Assumption Fee If LOAN|_APPLICATION Closingamount in Lender Amount does not LOAN_PURPOSE_Type = Agent Inter systemmust match match in Lender and “Purchase” Assumption Fee Closing Agentamount in Closing system. Agent system. 13 Lender/ Does Line 101 = SalesPrice on HUD-1 If LOAN|_APPLICATION Closing Line 401 = LOS (line 101 and401) LOAN_PURPOSE_Type = “Purchase” Agent Inter Sales Price? does notmatch value in Lender system. 14 Lender/ Deposit or Earnest EarnestMoney on If LOAN|_APPLICATION Closing Money on line 201 HUD-1 (line 201)LOAN_PURPOSE_Type = “Purchase” Agent Inter of HUD-1 must does not matchvalue equal amount in in Lender system. Loan Origination System. 15Closing Total Settlement Line 1400 on HUD-1 If LOAN|_APPLICATION AgentIntra Charges to seller does not match line LOAN_PURPOSE_Type =“Purchase” HUD-1 line 1400 502. must match Settlement Charges to selleron HUD-1 line 502. 16 Closing Contract Sales Price Contract Sales PriceIf LOAN|_APPLICATION Agent Intra on line 101 and 401 on HUD-1 (line 401)LOAN_PURPOSE_Type = of HUD-1 must be is not greater than “Purchase”greater than 0.00. 0.00. 17 Closing Contract Sales Price Contract SalesPrice If LOAN|_APPLICATION Agent Intra on line 101 and 401 on HUD-1(line 401) LOAN_PURPOSE Type = of HUD-1 must be should not be present“Refinance” equal to 0.00 or for refinances. null. Conditional onLOAN_PURPOSE_Type, LOAN_FEATURES_ConformingIndicator andCONSTRUCTION_REFINANCE_DATA GSERefinancePurposeType 18 Closing HUD line303 must Cash back to borrower If LOAN|_APPLICATION Agent Intra notexceed the exceeds the lesser of LOAN_PURPOSE_Type = lesser of 2% of the2% of principal “Refinance” principal amount or amount or $2000. ANDLOAN|_APPLICATION| $2000 for LOAN PRODUCT DATA|_LOAN_FEATURES conformingloans ConformingIndicator = that are not cash- “Y” ANDLOAN|_APPLICATION| out refinances. LOAN_PURPOSE|CONSTRUCTION_REFINANCE_DATA GSERefinancePurposeType(“NoCashOutFHAStreamlined Refinance”, “NoCashOutFREOwnedRefinance”,“NoCashOutOther”, “NoCashOutStreamlinedRefinance”, “ChangeInRateTerm”)Conditional on MORTGAGE_TERMS MortgageType 19 Lender First payment dateFirst Payment Date is If LOAN|_APPLICATION| Intra must be the first notfirst of month. MORTGAGE_TERMS day of the month MortgageType IN (“VA”,“FHA”) for VA and FHA insured loans. 20 Lender VA insured loans Loanamount exceeds If LOAN|_APPLICATION! Intra must not exceed VA limit of$240,000. MORTGAGE_TERMS MortgageType = $240,000. “VA” Conditional onMERS MERSRegistrationIndicator 21 Lender Loans registered MERS is notthe If LOAN|_APPLICATION|MERS Intra with MERS must loan's Mortgagee.MERSRegistrationIndicator = “Y” have MERS as the Mortgagee. 22 LenderLoans registered MERS MIN number If LOAN|APPLICATION! MERS Intra withMERS must is missing. MERSRegistrationIndicator = “Y” have a MIN number.Conditional on PROPERTY_State 23 Lender Flood Certification FloodCertification fee If LOAN|APPLICATION| Intra fees cannot be cannot becharged for PROPERTY_State = “Connecticut” charged for loan. propertiesin Connecticut. 24 Lender Document Document Preparation IfLOAN|APPLICATION| Intra Preparation fees fee cannot be charged PROPERTYState = “Texas” cannot be charged for loan. for properties in Texas. 25Lender Processing fees Processing fee cannot If LOAN|_APPLICATION| Intracannot be charged be charged for loan. PROPERTY_State = for propertiesin “Massachusetts” Massachusetts. 26 Lender Loans located in the Trusteename is If LOAN|APPLICATION| Intra following states missing.PROPERTY_State IN (Alaska, must have a trustee Arizona, California,Maryland, Texas, name: Alaska, Virginia, Washington, Arkansas, Arizona,Arkansas, Colorado, District of Columbia, Idaho, California,Mississippi, Missouri, Montana, Maryland, Texas, Nebraska, Nevada, NorthCarolina, Virginia, Oregon, Tennessee) Washington, Colorado, District ofColumbia, Idaho, Mississippi, Missouri, Montana, Nebraska, Nevada, NorthCarolina, Oregon, Tennessee 27 Lender/ For loans not Settlement Date onIf LOAN|_APPLICATION| Closing located in HUD-1 does not PROPERTY StateNOT IN Agent Inter California, Nevada, match value in Lender(“California”, “Nevada”, “Arizona”, Arizona, Hawaii, system. “Hawaii”,“New Mexico”, New Mexico or “Washington”) Washington, settlement date(Box 1) must match LOS closing date. Conditional on LOAN FEATURESConformingIndicator, PROPERTY_FinancedNumberOfUnits and PROPERTY_State28 Lender Conforming loans Loan amount exceeds If LOAN|_APPLICATION|Intra for single unit conforming limit of LOAN_PRODUCT_DATA| propertiesnot $322,700. LOAN_FEATURES located in Alaska or ConformingIndicator =“Y” and Hawaii must not LOAN|_APPLICATION| exceed $322,700.PROPERTY_Financed NumberOfUnits = “1” and LOAN|APPLICATION|PROPERTY_State <> (“Alaska” or “Hawaii”) 29 Lender Conforming loans Loanamount exceeds If LOAN|_APPLICATION| Intra for single unit conforminglimit of LOAN_PRODUCT_DATA|_LOAN_FEATURES properties located $484,050.ConformingIndicator = “Y” and in Alaska or LOAN|APPLICATION| Hawaii mustnot PROPERTYFinancedNumber exceed $484,050. OfUnits = “1” andLOAN|_APPLICATION| PROPERTY_State = (“Alaska” or “Hawaii”) Conditionalon LOAN_FEATURES EscrowWaiverIndicator 30 Lender/ The sum of linesInitial escrow deposit If LOAN|_APPLICATION| Closing 1001-1008 on the onHUD-1 (sum of LOAN_PRODUCT_DATA|_LOAN_FEATURES Agent Inter HUD1 mustmatch lines 1001-1008) does EscrowWaiverIndicator = “N” the initialescrow not match value in deposit amount in Lender system. the Lendersystem. 31 Lender/ Hazard insurance Number of months IfLOAN|_APPLICATION| Closing months escrowed escrowed for HazardLOAN_PRODUCT_DATA|_LOAN_FEATURES Agent Inter on HUD-1 (line Insurance onHUD-1 EscrowWaiverIndicator = “N” 1001) must match to does not matchvalue Loan Origination in Lender system. System value. 32 Lender/ Hazardinsurance Hazard insurance If LOAN|_APPLICATION| Closing amount permonth monthly amount on LOAN_PRODUCT_DATA|_LOAN_FEATURES Agent Inter onHUD-1(line HUD-1 does not EscrowWaiverIndicator = “N” 1001) must matchto match value in Lender Loan Origination system. System value. 33Lender/ Total hazard Total Hazard If LOAN|_APPLICATION|LOAN Closinginsurance escrow Insurance escrow PRODUCT DATA|_LOAN_FEATURES AgentInter amount on HUD-1 amount does not EscrowWaiverIndicator = “N” (line1001) must match value in Lender match to Loan system. OriginationSystem value. 34 Lender/ Mortgage Number of months IfLOAN|_APPLICATION|LOAN Closing insurance months escrowed for PRODUCTDATA|_LOAN_FEATURES Agent Inter escrowed on Mortgage Insurance onEscrowWaiverIndicator = “N” HUD-1 (line 1002) HUD-1 does not must matchto Loan match value in Lender Origination System system. value. 35Lender/ Mortgage Mortgage insurance If LOAN|_APPLICATION|LOAN Closinginsurance amount monthly amount on PRODUCT DATA|_LOAN_FEATURES AgentInter per month on HUD-1 does not EscrowWaiverIndicator = “N” HUD-1(line 1002) match value in Lender must match to system. Loan OriginationSystem value. 36 Lender/ Total mortgage Total Mortgage IfLOAN|_APPLICATION|LOAN Closing insurance escrow Insurance escrow PRODUCTDATA|_LOAN_FEATURES Agent Inter amount on HUD-1 amount does notEscrowWaiverIndicator = “N” (line 1002) must match value in Lender matchto Loan system. Origination System value. 37 Lender/ City property taxesNumber of months If LOAN|_APPLICATION|LOAN Closing months escrowedescrowed for City PRODUCT DATA|_LOAN_FEATURES Agent Inter on HUD-1 (lineProperty Taxes on EscrowWaiverIndicator = “N” 1003) must match HUD-1does not to Loan match value in Lender Origination System system. value.38 Lender/ City property taxes City Property Tax IfLOAN|_APPLICATION|LOAN Closing amount per month monthly amount onPRODUCT DATA|_LOAN_FEATURES Agent Inter on HUD-1 (line HUD-1 does notEscrowWaiverIndicator = “N” 1003) must match match value in Lender toLoan system. Origination System value. 39 Lender/ Total city propertyTotal City Property If LOAN|_APPLICATION|LOAN Closing taxes escrow Taxesescrow amount PRODUCT DATA|_LOAN_FEATURES Agent Inter amount on HUD-1does not match value EscrowWaiverIndicator = “N” (line 1003) must inLender system. match to Loan Origination System value. 40 Lender/ Countyproperty Number of months If LOAN|_APPLICATION|LOAN Closing taxes monthsescrowed for County PRODUCT DATA|_LOAN_FEATURES Agent Inter escrowed onHUD- Property Taxes on EscrowWaiverIndicator = “N” 1 (line 1004) mustHUD-1 does not match match to Loan value in Lender Origination Systemsystem. value. 41 Lender/ County property County Property Tax IfLOAN|_APPLICATION|LOAN Closing taxes amount per monthly amount onPRODUCT DATA|_LOAN_FEATURES Agent Inter month on HUD-1 HUD-1 does notmatch EscrowWaiverIndicator = “N” (line 1004) must value in Lender matchto Loan system. Origination System value. 42 Lender/ Total county TotalCounty Property If LOAN|_APPLICATION|LOAN Closing property taxes Taxesescrow amount PRODUCT DATA|_LOAN_FEATURES Agent Inter escrow amount ondoes not match value EscrowWaiverIndicator = “N” HUD-1 (line 1004) inLender system. must match to Loan Origination System value. 43 Lender/Annual Number of months If LOAN|_APPLICATION|LOAN Closing assessmentsescrowed for Annual PRODUCT DATA|_LOAN_FEATURES Agent Inter monthsescrowed Assessments on HUD- EscrowWaiverIndicator = “N” on HUD-1 (line1 does not match value 1005) must match in Lender system. to LoanOrigination System value. 44 Lender/ Annual Annual Assessments IfLOAN|_APPLICATION|LOAN Closing assessments monthly amount on PRODUCTDATA|_LOAN_FEATURES Agent Inter months escrowed HUD-1 does not matchEscrowWaiverIndicator = “N” on HUD-1 (line value in Lender 1005) mustmatch system. to Loan Origination System value. 45 Lender/ Annualassessments Total Annual If LOAN|_APPLICATION|LOAN Closing monthsescrowed on Assessment escrow PRODUCT DATA|LOAN Agent Inter HUD-1 (line1005) amount does not match FEATURES must match to Loan value in Lendersystem. EscrowWaiverIndicator = “N” Origination System value. 46 ClosingFor loans where Aggregate Escrow If LOAN|_APPLICATION|LOAN Agent Intraescrows are waived, adjusment is not blank. PRODUCT DATA|LOAN theaggregate FEATURES EscrowWaiverIndicator = escrow adjustment “Y” onlines 1007 and 1008 of the HUD-1 must be blank. 47 Closing If escrowsare not Escrow waiver fee If LOAN|_APPLICATION|LOAN Agent Intra beingwaived, an cannot be charged for PRODUCT DATA|LOAN “Escrow Waiver” loanswhere escrows are FEATURES EscrowWaiverIndicator = fee cannot be notwaived. “N” charged. Rule ID Rule Mapping Conditional on INTERVIEWERINFORMATION ApplicationTakenMethodType 1 ((LOAN|_APPLICATION|BORROWER|GOVERNMENT_MONITORING GenderType and LOAN|_APPLICATION|BORROWER|GOVERNMENT_MONITORING RaceNationalOriginType) cannot be null) ORLOAN|_APPLICATION|BORROWER| GOVERNMENT_MONITORINGRaceNationalOriginRefusalIndicator = “Y”. Conditional onBalloonlndicator 2 LOAN|_APPLICATION| LOAN_PRODUCT_DATA| LOAN_FEATURESMaturityDate MUST EQUAL ((LOAN|_APPLICATION| LOAN_PRODUCT_DATA|LOAN_FEATURES ScheduIedFirstPaymentDate plus LOAN|_APPLICATION|LOAN_PRODUCT_DATA| LOAN_FEATURES LoanOriginalMaturityTermMonths) minusone month). Conditional on LoanAmortizationType 3 LOAN|_APPLICATION|LOAN_PRODUCT_DATA|ARM RateAdjustmentLifetimeCapPercent cannot be null. 4LOAN|_APPLICATION| LOAN_PRODUCT_DATA| ARM_IndexMarginPercent cannot benull. 5 LOAN|_APPLICATION| LOAN_PRODUCT_DATA| ARM_IndexMarginPercentmust be in the format of xx.xxx (must be rounded to three places to theright of the decimal). Value must also be spelled out. 6LOAN|_APPLICATION| LOAN_PRODUCT_DATA|RATE_ADJUSTMENT_SubsequentCapPercent cannot be null. 7LOAN|_APPLICATION| LOAN_PRODUCT_DATA| RATE_ADJUSTMENT_InitialCapPercentcannot be null. 8 LOAN|_APPLICATION| LOAN_PRODUCT_DATA|RATE_ADJUSTMENT_FirstChangeFloor Percent cannot be null. 9LOAN|_APPLICATION| LOAN_PRODUCT_DATA| RATE_ADJUSTMENTFirstRateAdjustmentDate cannot be null. Conditional onLoanAmortizationType and ARM_ConversionOptionIndicator 10(LOAN|_APPLICATION| LOAN_PRODUCT_DATA|ARM|_CONVERSION_OPTION_FeeAmount,LOAN|_APPLICATION| LOAN_PRODUCT_DATA|ARM|_CONVERSION_OPTION_FeePercent,LOAN|_APPLICATION|LOAN_PRODUCT_DATA_ARM|_CONVERSION_OPTION_PeriodEndPayment Number,LOAN|_APPLICATION|LOAN_PRODUCT_DATA|ARM|_CONVERSION_OPTION_PeriodStartPayment Number)cannot be null Conditional on LOAN_PURPOSE Type 11LOAN|_APPLICATION|RESPA_FEE|_PAYMENT_Paid ByTypeThirdPartyName whereLOAN|_APPLICATION| RESPA_FEE_SpecifiedHUDLineNumber = ‘807’ Data pointfrom Lender data file and data point from Closing Agent data file mustbe the same. 12 LOAN|_APPLICATION|RESPA_FEE|_PAYMENT_Amount whereLOAN|_APPLICATION| RESPA_FEE_SpecifiedHUDLineNumber = ‘807’ Data pointfrom Lender data file and data point from Closing Agent data file mustbe the same. 13 ((LOAN|_CLOSING_DOCUMENTS|RESPA_HUD_DETAIL_LineItemAmount where LOAN|_CLOSING_DOCUMENTS|RESPA_HUD_DETAIL SpecifiedHUDLineNumber = ‘101’ MUST EQUALLOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_LineItemAmount whereLOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_SpecifiedHUDLine Number =‘401’) in Closing Agent file). These values must both equal LenderField: LOAN|_APPLICATION| TRANSACTION_DETAIL PurchasePriceAmount 14(LOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_LineItemAmount whereLOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_SpecifiedHUDLine Number =‘201’) from Closing Agent file MUST EQUAL (LOAN|_APPLICATION|TRANSACTION_DETAIL| PURCHASE_CREDIT_Amount where LOAN|_APPLICATION|TRANSACTION_DETAIL| PURCHASE_CREDIT_Type = “EarnestMoney”) 15LOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_LineItemAmount whereLOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_SpecifiedHUDLine Number =‘1400’ and LOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_Line ItemPaidByType= “Seller” MUST EQUAL LOAN|_CLOSING_DOCUMENTS|RESPA_HUD_DETAIL_LineItemAmount where LOAN|_CLOSING_DOCUMENTS|RESPA_HUD_DETAIL_SpecifiedHUDLine Number = ‘502’ 16LOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_LineItemAmount whereLOAN|_CLOSING DOCUMENT| RESPA_HUD_DETAIL_SpecifiedHUDLine Number IN(‘101’, ‘401’) must be >0.00. 17 LOAN|_CLOSING_DOCUMENTS|RESPA_HUD_DETAIL_LineItemAmount where LOAN|_CLOSING_DOCUMENTS|RESPA_HUD_DETAIL_SpecifiedHUDLine Number IN (‘101’, ‘401’) MUST BE (=0.00 or NULL). LOAN| RESPA_HUD_DETAIL_LineItemAmount whereLOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_SpecifiedHUDLine Number IN(‘101’, ‘401’) MUST BE (= 0.00 or NULL). Conditional onLOAN_PURPOSE_Type, LOAN_FEATURES_ConformingIndicator andCONSTRUCTION_REFINANCE_DATA GSERefinancePurposeType 18LOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_LineItemAmount (whereLOAN|_CLOSING DOCUMENTS| RESPA_HUD_DETAILSpecifiedHUDLine Number =‘303’) MUST BE <= (the lesser of (.02 * LOAN| APPLICATION|MORTGAGE_TERMS LoanAmount OR $2000)) in Conditional on MORTGAGE_TERMSMortgageType 19 ((LOAN|_APPLICATION|LOAN PRODUCT DATA|LOAN_FEATURESScheduledFirstPaymentDate (DD)) MUST = “1” 20 LOAN|_APPLICATION!MORTGAGE_TERMS LoanAmount MUST BE <= 240,000. Conditional on MERSMERSRegistrationIndicator 21 LOAN|_APPLICATION|MERSMERSOriginalMortgageeOfRecordIndicator MUST = ‘Y’ 22LOAN|_APPLICATION|MERS|MERS MINIdentifier cannot be null Conditional onPROPERTY_State 23 LOAN|_APPLICATION|RESPA_FEE|_PAYMENT Amount whereLOAN|._APPLICATION|RESPA_FEE_Type = “FloodCertification” must be 0.00 ornull. 24 LOAN|_APPLICATION|RESPA_FEE|_PAYMENT_Amount where LOAN|APPLICATION|RESPA_FEE_Type = “DocumentPreparationFee” must be 0.00 ornull. 25 LOAN|_APPLICATION|RESPA_FEE|_PAYMENT Amount whereLOAN|_APPLICATION|RESPA_FEE_Type = “ProcessingFee” must be 0.00 or null.26 LOAN|CLOSING DOCUMENTS| RECORDABLE DOCUMENT| TRUSTEE_UnparsedNamemust not be null. 27 LOAN|_CLOSING_DOCUMENTS| LOAN_DETAILS ClosingDateData point from Lender data file and data point from Closing Agent datafile must be the same. Conditional on LOAN FEATURES ConformingIndicator,PROPERTY_FinancedNumberOfUnits and PROPERTY_State 28 LOAN|APPLICATION|MORTGAGE_TERMS LoanAmount must be <=322,700. 29 LOAN|APPLICATION|MORTGAGE_TERMS LoanAmount must be <=484,050. Conditional onLOAN_FEATURES EscrowWaiverIndicator 30 Sum (LOAN|_APPLICATION|RESPA_FEE|_PAYMENT_Amount where LOAN|_APPLICATION|RESPA_FEE_SpecifiedHUDLineNumber = “1001’, 1002’, ‘1003’, ‘1004’,‘1005’, ‘1006’, ‘1007’, ‘1008’) Sum from Lender file and Closing Agentfile should be the same. 31 LOAN|APPLICATION|ESCROWCollectedNumberOfMonthsCount where LOAN! APPLICATION!ESCROWJtemType = ‘HazardInsurance” Data point from Lender data file anddata joint from Closing Agent data file must be the same. 32LOAN|APPLICATION| ESCROW_MonthlyPaymentAmount where LOAN|_APPLICATION|ESCROW_ItemType = “HazardInsurance” Data point from Lender data file anddata joint from Closing Agent data file must be the same. 33LOAN|_CLOSING DOCUMENTS| RESPA_HUD_DETAIL_LineItemAmount whereLOAN|_CLOSING DOCUMENTS| RESPA_HUD_DETAIL_SpecifiedHUDLine Number =“1001” Data point from Lender data file and data point from ClosingAgent data file must be the same. 34 LOAN|_APPLICATION|MI_DATAMICollectedNumberOfMonthsCount Data point from Lender data file and datapoint from Closing Agent data file must be the same. 35LOAN|APPLICATION|MI DATA| MI_RENEWAL_PREMIUM_MonthlyPayment Amount Datapoint from Lender data file and data point from Closing Agent data filemust be the same. 36 LOAN|_CLOSING_DOCUMENTS|RESPA_HUD_DETAIL_LineItemAmount where LOAN|CLOSING DOCUMENTS|RESPA_HUD_DETAIL_SpecifiedHUDLine Number = “1002” Data point from Lenderdata file and data point from Closing Agent data file must be the same.37 LOAN|_APPLICATION| ESCROWCollectedNumberOfMonthsCount whereLOAN|_APPLICAT10N| ESCROW_temType = “CityPropertyTax” Data point fromLender data file and data point from Closing Agent data file must be thesame. 38 LOAN|_APPLICATION|ESCROW MonthlyPaymentAmount whereLOAN|_APPLICATION|ESCROW_ItemType = “CityPropertyTax” Data point fromLender data file and data point from Closing Agent data file must be thesame. 39 LOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_LineItemAmount whereLOAN|_CLOSING DOCUMENTS| RESPA_HUD_DETAIL_SpecifiedHUDLine Number =“1003” Data point from Lender data file and data point from ClosingAgent data file must be the same. 40 LOAN|_APPLICATION|ESCROW_CollectedNumberOfMonthsCount where LOAN|APPLICATION|ESCROW_ItemType = “CountyPropertyTax” Data point from Lender data fileand data point from Closing Agent data file must be the same. 41LOAN|_APPLICATION|ESCROW MonthlyPaymentAmount where LOAN|APPLICATION|ESCROW_ItemType = “CountyPropertyTax” Data point from Lenderdata file and data point from Closing Agent data file must be the same.42 LOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL_LineItemAmount whereLOAN|CLOSING DOCUMENTS| RESPA_HUD_DETAIL_SpecifiedHUDLine Number =“1004” Data point from Lender data file and data point from ClosingAgent data file must be the same. 43LOAN|APPLICATION|_ESCROW_CollectedNumberOfMonthsCount whereLOAN|_APPLICATION| ESCROW_ItemType = “Assessment” Data point from Lenderdata file and data point from Closing Agent data file must be the same.44 LOAN|_APPLICATION|_ESCROW MonthlyPaymentAmount whereLOAN|_APPLICATION|ESCROW_ItemType = “Assessment” Data point from Lenderdata file and data point from Closing Agent data file must be the same.45 LOAN|_CLOSING_DOCUMENTS| RESPA_HUD_DETAIL LineItemAmount whereLOAN|_CLOSING DOCUMENTS| RESPA_HUD DETAIL SpecifiedHUDLineNumber =“1005” Data point from Lender data file and data point from ClosingAgent data file must be the same. 46 LOAN|_CLOSING DOCUMENTS|RESPA_HUD_DETAIL LineItemAmount where (where LOAN|CLOSINGDOCUMENTS|RESPA_HUD_DETAIL SpecifiedHUDLineNumber = “1007” or “1008”)MUST BE null or 0.00 47 LOAN|_APPLICATION|_RESPA_FEE_PAYMENT Amountwhere (LOAN|_APPLICATION| RESPA_FEE_Type = “EscrowWaiverFee”) MUST BE =0.00 or null

Although Table 2 offers a sample listing of rules and corresponding rulesets for various scenarios, as indicated the rules can be variouslyorganized. Table 3 offers another example of a rules organization. Here,the rules are organized according to the document type and the closingstatus. The values of these two parameters dictates the identificationof the rules in the rule sets. For example, a pre-closing HUD-1 formexamination entails different rules than the post-closing review of thesame form. Similarly, other types of forms entail different rules evenif the closing status is the same. Again, these rules are offered by wayof example. The ordinarily skilled artisan will recognize thealternatives.

TABLE 3 Rules by Closing Status and Document Type Pre- Post- ClosingClosing Ref. No. Check? Check? Subject Document Review Task N-1 X X NoteVerify Document/Closing Date (Except in Dry Funding States) N-2 X X NoteVerify Loan Amount N-3 X X Note Verify Principal & Interest Payment N-4X Note Verify Borrower Names (on first page & signature lines) N-6 X XNote Determine whether the loan will be FHA-Insured N-6a X X Note If N-6= “Yes”, Verify FHA Case Number N-6b X Note If N-6 = “Yes”, Verify FHAAllonge Signed/Complete N-7 X X Note Verify First Payment Date N-8 XNote Determine whether a Power of Attorney applies N-8a X Note If N-8 =“Yes”, Verify signatures against POA N-9 X X Note Verify Maturity DateN-10 X Note Verify all white-out/strikethrough areas are initialed N-llX X Note Verify Loan Number N-12 X X Note Determine whether the loan isan ARM N-12a X X Note Verify Change Date N-12b X X Note Verify MarginN-12c X X Note Verify Index N-12d X Note Verify Conversion Options arecorrect N-12e X Note Verify Payment Change Caps/Ceiling/Floor N-12f XNote Verify “ARM Confirmation” in file N-12g X Note Verify ARM docs areappropriate for the program N-13 X Note Verify Note is Valid in PropertyState N-14 X X Note Verify Interest Rate N-15 X Note Verify PropertyAddress N-16 X Note Verify Late Charge Terms by product and state N-17 XNote Verify that Signed Original Document is Present N-18 X Note VerifyAll Pages Are Present N-19 X Note Verify Lender Name N-20 X Note VerifyEndorsement Accuracy N-21 X Note Verify Balloon AddendumPresent/Accurate (if applicable) SI-1 X X Security Instrument VerifyDocument Date (Except in Dry Funding States) SI-2 X X SecurityInstrument Verify Loan Amount SI-3 X Security Instrument Verify BorrowerNames Signed as Typed SI-4 X X Security Instrument Verify Loan NumberSI-5 X X Security Instrument Verify Legal Description SI-6 X X SecurityInstrument Verify Property Address SI-7 X X Security Instrument VerifyMaturity Date SI-8 X X Security Instrument Verify all appropriate ridersare attached SI-9 X Security Instrument Verify Borrower Name(s) &Signature Lines against Vesting SI-10 X Security Instrument If N-6 =“Yes”, Verify FHA Case Number SI-11 X Security Instrument Verify CountySI-12 X Security Instrument Verify All Pages Are Present SI-13 XSecurity Instrument Verify Lender Name SI-13 X X Security InstrumentVerify MERS Number ARM-1 X ARM Rider Verify Change Date ARM-2 X ARMRider Verify Margin ARM-3 X ARM Rider Verify Index ARM-4 X ARM RiderVerify Conversion Options are correct ARM-5 X ARM Rider Verify Documentsare appropriate for the program HUD-1 X HUD-1 Verify no StateUnallowable Charges HUD-2 X HUD-1 Verify no FHA/VA Unallowable ChargesHUD-3 X HUD-1 Verify no Other Unallowable Charges HUD-4 X HUD-1 CompareDeposit Amount to Purchase Agreement HUD-5 X HUD-1 Verify Interim(Prepaid) Interest HUD-6 X HUD-1 Verify Buyer/Seller Signatures arepresent HUD-7 X X HUD-1 Verify Underwriting Fee HUD-8 X X HUD-1 VerifyDocument Preparation Fee HUD-9 X HUD-1 Verify Origination Fee (Line 801)HUD-10 X HUD-1 Verify Discount Fee (Line 802) HUD-11 X HUD-1 VerifyCredit Report Fee (Line 804) HUD-12 X HUD-1 Verify Appraisal Fee (Line803) HUD-13 X HUD-1 Verify Lender's Inspection Fee (Line 805) HUD-14 XHUD-1 Verify Mortgage Insurance Application Fee (Line 806) HUD-15 XHUD-1 Verify Assumption Fee (Line 807) HUD-16 X HUD-1 Verify CLO AccessFee (Section 800) HUD-17 X HUD-1 Verify Tax Service Fee (“Tax RelatedService Fee” per DTD-Section 800) HUD-18 X HUD-1 Verify Buydown Fee(Section 800-Text String Search) HUD-19 X HUD-1 Verify Construction Fee(Section 800~Text String Search) HUD-20 X HUD-1 Verify Yield SpreadDifferential (Section 800~Text String Search) HUD-21 X HUD-1 Verify LoanProcessing Fee (“Processing Fee” per DTD-Section 800) HUD-22 X HUD-1Verify Application Fee (Section 800) HUD-23 X HUD-1 Verify StateBond/Agency Fee (Section 800) HUD-24 X HUD-1 Verify Commitment Fee(Section 800) HUD-25 X HUD-1 Verify Supplemental Orig Fee (Section 800)HUD-26 X HUD-1 Verify Flood Determination Fee (DTD = “FloodCertification” ~ Section 800) HUD-27 X HUD-1 Verify Flood Zone Fee(Section 800-Text String Search) HUD-28 X HUD-1 Verify MCC Fee (Section800-Text String Search) HUD-29 X HUD-1 Verify Bond Participation Fee(Section 800-Text String Search) HUD-30 X HUD-1 Verify “Reservation Fee”(Section 800-Text String Search) HUD-31 X HUD-1 Verify TEX/VETOrigination Fee (Section 800- Text String Search) HUD-32 X HUD-1 VerifyPERS Review Fee (Section 800-Text String Search) HUD-33 X HUD-1 VerifyCHFA Max Fee (Section 800-Text String Search) HUD-34 X HUD-1 VerifyCALRA Mortgage Loan Review Fee (Section 800-Text String Search) HUD-35 XHUD-1 Verify CALRA Compliance Review Fee (Section 800-Text String SearchHUD-36 X HUD-1 Verify Compliance Inspection Fee (Section 800- TextString Search) HUD-37 X HUD-1 Verify Deposit Verification Fee (Section800- Text String Search) HUD-38 X HUD-1 Verify Housing Second MortgageFee (Section 800-Text String Search) HUD-39 X HUD-1 Verify InsuranceTracking Fee (Section 800-Text String Search) HUD-40 X HUD-1 Verify MERSRegistration Fee (Section 800-Text String Search) HUD-41 X HUD-1 VerifyConst-Perm Administration Fee (Section 800-Text String Search) HUD-42 XHUD-1 Verify Quality File Fee-Wholesale Only (Section 800-Text StringSearch) HUD-43 X HUD-1 Verify Construction Interst (Section 900-TextString Search) HUD-44 X HUD-1 Verify Per Diem Interest Differential(Section 900- Text String Search) HUD-45 X HUD-1 Verify ContingencyReserve (Section 1300-Text String Search) HUD-46 X HUD-1 Verify PITIReserves (Section 1300-Text String Search) HUD-47 X HUD-1 VerifyAdministration Fee (Section 1300-Text String Search) HUD-48 X HUD-1Verify Amortization Schedule Fee (DTD: “Amortization Fee”-Section 1300)HUD-49 X HUD-1 Verify Loan Assignment Fee (Section 1300) HUD-50 X HUD-1Verify Loan Disbursement Fee (Section 1300- Text String Search) HUD-51 XHUD-1 Verify Wire Fee (Section 1300-Text String Search) HUD-52 X HUD-1Verify Escrow Waiver Fee (Section 1300) HUD-53 X HUD-1 VerifyMiscellaneous Fee in APR (Section 1300- Text String Search) HUD-54 XHUD-1 Verify MCC Application Extension Fee (Section 1300-Text StringSearch) HUD-55 X HUD-1 Verify MCC Closing Extension Fee (Section 1300-Text String Search) HUD-56 X HUD-1 Verify MCC Late Fee (Section1300-Text String Search) HUD-57 X HUD-1 Verify Escrow HoldbackInspection Fee (Section 1300-Text String Search) HUD-58 X HUD-1 VerifyDocument Review Fee (Section 1300-Text String Search) HUD-59 X HUD-1Verify Const Perm Future Funds to Dis (Section 1300-Text String Search)HUD-60 X HUD-1 Verify Constr/Perm Initial Draw (Section 1300- TextString Search) HUD-61 X HUD-1 Verify Constr/Perm Second Draw (Section1300- Text String Search) HUD-62 X HUD-1 Verify Constr/Perm Third Draw(Section 1300- Text String Search) HUD-63 X HUD-1 Verify Constr/PermFour Draw (Section 1300- Text String Search) HUD-64 X HUD-1 VerifyConstr/Perm Escrow Holdback (Section 1300-Text String Search) HUD-65 XHUD-1 Verify All Title-Related Charges HUD-66 X HUD-1 Verify Presence ofHUD-1 Addendum & Signatures HUD-67 X HUD-1 Verify allwhite-out/strikethrough areas are initialed HUD-68 X X HUD-1 Verify netfunding amount: calculated according to the formula [LOAN AMT less theSum of Fees verified in Rules HUD-6 thru HUD-69] TIL-1 XTruth-in-Lending Verify that all appropriate Statements are CompletedTIL-2 X Truth-in-Lending Verify that borrowers have signed TIL-3 XTruth-in-Lending Verify Date TIL-4 X Truth-in-Lending Verify BorrowerName(s) TIL-5 X Truth-in-Lending Verify that APR is reasonable TIL-6 XTruth-in-Lending Verify P&I Payment Amount TIL-7 X Truth-in-LendingVerify Prepayment Penalty Status TIL-8 X Truth-in-Lending Verify LoanAmount TIL-9 X Truth-in-Lending Verify Signature Lines TIL-10 XTruth-in-Lending Verify Late Charge Terms PL-1 X Payment Letter VerifySignatures PL-2 X Payment Letter Verify Totals are Accurate PL-3 XPayment Letter Verify Loan Number TC-1 X X Title Commitment VerifyPresence of Title Commitment TC-2 X X Title Commitment Verify LegalDescription TC-3 X X Title Commitment Verify No Unallowable ExceptionsTC-4 X X Title Commitment Verify Correct Mortgagee TC-5 X X TitleCommitment Verify Correct Mortgagor TC-6 X X Title Commitment VerifyDate Issued (earlier than closing date) TC-7 X Title Commitment VerifyPolicy Jacket Present HAZ-1 X X Hazard Insurance Verify Presence ofOriginal Policy or Binder HAZ-2 X X Hazard Insurance Verify AdequateCoverage HAZ-3 X X Hazard Insurance Verify Adequate Term (1 Year Min)HAZ-4 X X Hazard Insurance Verify Borrower Names HAZ-5 X X HazardInsurance Verify Property Address HAZ-6 X X Hazard Insurance VerifyCorrect Mortgagee Clause HAZ-7 X X Hazard Insurance Verify Flood PolicyPresent (if Required) CI-1 X Closing Instructions VerifySettlement/Escrow Agent Information CI-2 X Closing Instructions VerifyFHA/VA Case Number CI-3 X Closing Instructions Verify Loan Number CI-4 XClosing Instructions Verify Term CI-5 X Closing Instructions VerifyBorrower Name(s) & Vesting CI-6 X Closing Instructions Verify 1stPayment Date CI-7 X Closing Instructions Verify Impounds/Taxes CI-8 XClosing Instructions Verify Loan Amount CI-9 X Closing InstructionsVerify P&I Payment Amount CI-10 X Closing Instructions Verify PropertyAddress CI-11 X Closing Instructions Verify Endorsements CI-12 X ClosingInstructions Verify Preliminary Exceptions CI-13 X Closing InstructionsVerify Maturity Date CI-14 X Closing Instructions Verify Sales PriceCI-15 X Closing Instructions Verify County A-1 X Assignment Verify DateA-2 X Assignment Verify Loan Number A-3 X Assignment Verify BorrowerName (agree to Vesting) A-4 X Assignment Verify County A-5 X AssignmentVerify Legal Description A-6 X Assignment Verify Notary Section CompleteA-7 X Assignment Verify Signed by Notary A-8 X Assignment VerifyAssistant Secretary Signature A-9 X Assignment Verify Notary Stamp ClearA-10 X Assignment Verify Present MISC-1 X Loan Application VerifyPresent and Signed MISC-2 X HUD 92900 Add. Verify Present and SignedMISC-3 X VA1802AAdd. Verify Present and Signed MISC-4 X FHA Source ofVerify Present and Signed Funds MISC-5 X Closing Affidavit VerifyPresent and Signed MISC-6 X Tax Information Verify Present Sheet MISC-7X Notice to Borrower Verify Present MISC-8 X FHA/VA Verify PresentEscrow Agreement MISC-9 X Survey & Affidavit Verify Present MISC-10 XInitial Escrow Disc. Verify Present and Signed MISC-11 X X Right toCancel Verify Present MISC-12 X Right to Cancel Verify Signed MISC-13 XOccupancy Verify Present and Signed Agreement

The EQC rules, such as are represented in these tables, are stored inthe EQC rules repository 510 using conventional techniques for storingand organizing data. The EQC rules repository 510 can be a separatedatabase of the rules, as described, or could equally by embedded incode that provides the EQC system functionality. The EQC rulesrepository will be periodically updated to reflect additions to therules and changes to existing rules. Facilities for submitting newrules, such as where a lender would like to include an additionalcondition on an EQC request process particularly pertaining to theirdocuments, are also preferably provided. Additionally, parties cancreate and provide their own particular rules, as described above.

Where the document publication feature is implemented, the EQC rulesrepository may be further organized to include categories that areuseful for that feature. Particularly where the analyzed datasets andcorresponding EQC results file are organized as an XML based electronicdocuments, the rules may be organized as follows. The five categoriescorrespond to those introduced in the description of the Issues Summarysection of the EQC results report described above. Namely, the firstcategory of issues is comparison of lender and closing agent data. Theserules may be identified by a type attribute value of“Lender/ClosingAgentInter” and appear in the Lender/Closing Agent DataSet Differences section. An example of the format for such rules isprovided in Table 4 as follows:

TABLE 4 LENDER CLOSING CLOSING AGENT DOCUMENT DATASET DOCUMENT DATASETRULE ID FAILED RULE VALUE VALUE RULE_Identifier RULE_NameCHECKED_DATA_DisplayName “=” CHECKED_DATA CHECKED DATA_Value DisplayName“=” Where CHECKED_DATA CHECKED DATA_Value DataSourceIdentifier = WhereCHECKED_DATA_DataSourceIdentifier = “Lender” and “ClosingAgent” andCHECKED_DATA_DataSetIdentifer = CHECKED_DATA_DataSetIdentifer =“Printed” “Printed”

The second category is errors in the lender's data set, which may beidentified by the type attribute value of “LenderIntra” and appear inthe Lender Issues For Available Data Sets section. An example of theformat for such rules is provided in Table 5:

TABLE 5 LENDER LENDER CLOSING ORIGINATION DOCUMENT DATASET SYSTEMDATASET RULE ID FAILED RULE VALUE VALUE RULE_Identifier RULE_NameCHECKED_DATA CHECKED_DATA DisplayName “=” DisplayName “=”CHECKED_DATA_Value CHECKED_DATA_Value Where CHECKED_DATA WhereCHECKED_DATA

The third category is differences between a lender's system and printeddocuments data sets. These rules are identified by a type attributevalue of “LenderDiff” and appear in the Lender Data Set Differencessection. Table 6 illustrates an example of the format for these rules.

TABLE 6 LENDER CLOSING DOCUMENT DATASET LENDER ORIGINATION DATA NAMEVALUE SYSTEM DATASET VALUE CHECKED_DATA CHECKED_DATA_ValueCHECKED_DATA_Value DisplayName Where CHECKED_DATA Where CHECKED_DATADataSourceIdentifier = “Lender” DataSourceIdentifier = “Lender” andCHECKED_DATA_DateSetIdentifer = and CHECKED_DATA_DateSetIdentifer =“Printed” “System”

The forth category is errors in the closing agent's data set, which maybe identified by a type attribute value of “ClosingAgentIntra” andappear in the Closing Agent Data Set Issues section. An example formatfor these rules is in Table 7.

TABLE 7 CLOSING AGENT DOCUMENT DATASET CLOSING AGENT SYSTEM RULE IDFAILED RULE VALUE DATASET VALUE RULE_Identifier RULE_NameCHECKED_DATA_DisplayName “=” CHECKED_DATA_DisplayName “=”CHECKED_DATA_Value CHECKED_DATA_Value Where WhereCHECKED_DATA_DataSourceIdentifier = CHECKED_DATA_DataSourceIdentifier =“ClosingAgent” and “ClosingAgent” and _DataSetIdentifer = “Printed”_DataSetIdentifer = “System”

Lastly, the fifth category of issues is differences between a closingagent's system and printed documents data sets. These rules may beidentified by a type attribute value of “ClosingAgentDiff” and appear inthe Closing Agent Data Set Differences section, with a format as shownin Table 8.

TABLE 8 CLOSING AGENT CLOSING CLOSING AGENT DOCUMENT DATASET ORIGINATIONSYSTEM DATA NAME VALUE DATASET VALUE CHECKED_DATA CHECKED_DATA_ValueCHECKED_DATA_Value DisplayName Where CHECKED_DATA Where CHECKED_DATADataSourceIdentifier = DataSourceIdentifier = “ClosingAgent” and“ClosingAgent” and CHECKED_DATA CHECKED_DATA DataSetIdentifer =“Printed” DataSetIdentifer = “System”

As can be seen in the values corresponding to various datasets, theterms “System” and “Printed” are used. When used in conjunction with thepublication feature of the present invention, the value “Printed” is anindicia that documents corresponding to the dataset have been published,such as for usage in a closing. Datasets retaining the value “System”are not yet published. Notably, a user may print documents from thisdataset without causing them to be considered as published. For example,a Closing Agent (or other user, be it a Lender, Borrower, etc.) mightwant to print a copy for proofreading, to allow a client (e.g. Borrower)to review the documents, or for any number of reasons. In this instance,the system retains the “system” value in association with the relevantdataset even though the documents have been printed. Only when thedocuments are formally printed for usage, which is also referred to aspublishing them, is the value for the dataset changed from “system” to“printed”. Additionally, as will be seen with regard to the publicationprocess discussed further in connection with FIG. 10 below, when aclosing package is officially printed (aka published) for a closing,each of the documents in the package are versioned accordingly.

In the example provided above, there are thus four types of datasets onthe EQC system. They are “Lender System”, “Lender Printed” (aka LenderPublished), “Closing Agent System”, and “Closing Agent Printed” (akaClosing Agent Published). Each of those datasets are labeledaccordingly.

The EQC rules engine 506 includes conventional facilities for examiningthe database of rules and extracting the appropriate rule set dependingupon the EQC request. For example, with reference to the rules in Table2, certain EQC requests will require accessing rules having a given“Rule Type”; alternatively, with reference to Table 3, certain EQCrequests will require accessing rules pertaining to a given closingstatus and given document type.

The EQC rules engine 506 thus communicates with the EQC rules repository510 to acquire the necessary rule sets and member rules, for applicationto the data. An initial validation preferably precedes application ofthe EQC specific rules to the data, particularly where the EMD is aformal electronic document. This initial validation will comprise aconventional (e.g., XML) validation against a DTD for the formalelectronic document, followed by additional custom document validationto check for the integrity of the EMD, such as whether view data matchescorresponding main data found in the EMD. Commonly owned applicationSer. No. 10/339,775 entitled “Electronic Document Validation” providesmore information about these preliminary validation processes.

The EQC rules are then applied to the document. Whether the EMD is anXML-only data set or a formal electronic document containing an XML datasection, the EMD will have known fields (e.g., defined by XML elements),having corresponding values. Conventional processing techniques are thenused to identify the presence of the elements and obtain thecorresponding values where required. Once the values are retrieved, thelogical mappings are then applied, again using conventional processingtechniques. For example, Rule ID #14 in Table 2 indicates that thedeposit or earnest money on line 201 of HUD-1 must equal the amount inthe LOS. There, the values for the relevant fields in the HUD-1 and theLOS data are retrieved, and compared to determine that they match. Ifthey do not match, an instance of an error for Rule ID #14 ismaintained, so that the subsequently produced report can reflect themismatch. The EQC rules engine 506 preferably processes all of the rulesin the identified rule set until they have been exhausted. Uponcompletion, the EQC rules engine 506 reports the same to the EQC ResultsModule 508.

The EQC Results Module 508 communicates with the EQC rules engine 506and thus receives the list of failed rules. If no rules have failed,then the EQC Results Module 508 prepares a report indicating nofindings, or a “pass” result pertaining to the EQC request. If there arefailed rules, then the corresponding error messages are retrieved fromthe rule sets (e.g., from the repository or the rules engine) and arecompiled to provide a report. One preferred EQC report format uses thesame format as was used for the EQC request. A viewable and/or printablereport is provided in the EQC report. The EQC report can also use theformal electronic document standard.

Particularly where the document publication aspect of the presentinvention is practiced, the results file and corresponding report may beprovided by initially checking for the appropriate datasets, which canbe accommodated by examining fields in the datasets indicating the typeand version of the dataset being examined. In XML embodiments, this maybe accommodated by examining relevant elements, which may alone providethe dataset type and/or version information or collectively provide suchinformation (e.g., the type information may be a concatenation of valuescorresponding to the source (e.g., Lender, or Closing Agent) and type(e.g., Origination System, Closing Document) information). Thisinformation is used as the initial basis for determining whether the(e.g., lender, closing agent) datasets are present for examination, andalso for populating the above described EMD summary section (e.g., FIG.9A, 904). The remaining functionality is provided by applying theappropriate rules to the datasets and issuing EQC results as described.The EQC rules and results modules are also configured to provide thedocument publication functionality that is described further below, andin connection with providing reports with the document manifest.

The EQC system 500 can be variously embodied. The EQC system 500 canentirely comprise software that is stored in conventional media andexecuted by a conventional processor to provide the above describedfunctionality. The EQC system 500 can also be embodied in the form of acomputer system having such as processor and storing such software forexecution. These and other alternatives will be recognized by theartisan.

The EQC System can be invoked pursuant to various transactions. Theschematic diagram of FIG. 7 provides an overview of various examples oftransactions in the life cycle of an electronic mortgage document.Participants in the illustrated process include the lender 702, closingagent 704, recorder 706, servicing agent 708, investor 710, andcustodial services 712. Where electronic documents are being handled,these parties 702-712 can variously communicate over a computer networkto effect a mortgage transaction utilizing the certified electronicmortgage document, such as those previously described between thelender, certifying agent, and investor. Additionally, before or afterthese mortgage transactions, the EQC system provides EQC resultscorresponding to EQC requests as described above. This includes“downstream” transactions that occur after the closing.

As described above, loan documents are prepared 720, such as via alender's loan origination system (LOS), and the electronic mortgagedocument can reside on the LOS or can be uploaded from a documentpreparer located at a remote location via the computer network. Theclosing agent 704 receives closing instructions from the lender and theclosing documents. Closing package creation 722 can be centralized sothat the lender 702 and closing agent 704 can provide the necessaryclosing data and electronic documents to complete a closing package.Additionally, the closing agent 704 can invoke information provided bythe lender 702, and vice versa.

Upon completion of the closing package, a closing 724 involving atraditional ink and pen signing, or digital signing, of relevantdocuments including the paper mortgage note follows, with the borrowersigning the necessary documents. Recording 706 of the executed documentscan then proceed, with the recordable documents being sent forrecordation, and corresponding indicia of what is recorded.

Also indicated is post closing quality assurance 726, which is providedby the EQC system. Example participants include the servicing agent 708,investor 710 and custodial services 712. Use of the EQC system ensuresand confirms that data is consistently implemented for all of thedifferent documents pertaining to the loan, and provides additionalquality control aspects as dictated by the rule set. According to thisaspect, in addition to applying a first rule set (e.g., for the lenderpursuant to a closing) to an EMD corresponding to a closing package, theEQC system receives a second electronic data set for a related function.One example of a related function is that provided by the closing agent,as described above. Other examples of related functions are thoseprovided by the servicing agent, appraiser, and other entities. The EQCsystem receives the second EMD and applies a second set of qualitycontrol rules to the second EMD. Results of this process can beiterative, depending upon satisfaction of the rules, and ultimately willresult in an EQC pass result after corrections are made. Here, positiveEQC results indicate the second EMD is consistent with the first EMD andappropriate for the function, which again is dictated by rules that canbe submitted by the service provider, or combinations of parties. Forexample, the servicing package that is implemented by the servicingagent 708 is subject to an EQC check following the closing and prior tothe exchange. Here, the data in the servicing agent system is submittedto the EQC system to ensure that it is consistent with data that waspreviously used for the loan pursuant to the closing, and to ensurecompliance with any other rules, including those defined by theservicing agent. The servicing agent data for the closing note, deed oftrust, assignment, first payment letter, hazard insurance and taxinformation sheets is among that which is compared to the existing databy the EQC system. This process uses the same type of comparison offield values as described above.

Similarly, as described above in more detail, the investor 710implements the EQC system in connection with receipt of the deliverypackage for the loan. Additionally, in connection with the loan beingheld by the document custodian, wherein the signed closing package andpaper documents are provided, the content of the documents can beverified using the EQC system.

FIG. 10 is a flow diagram illustrating an embodiment of a process 1000for publishing documents. The above-described document manifest andrelated features are useful for transactions such as the publication ofdocuments pursuant to a closing, as the manifest allows the opportunityfor users to check the list of documents and corresponding version toensure inclusion of the appropriate documents, as well as the correctversions of those documents. The above-described usage of an indicatoron paper mortgage documents that ties the paper document to anelectronic dataset as well as the corresponding EQC result for thatdataset is also useful for implementing this process 1000. The indicatormay be variously provided, such as in the form of a string field createdby document providers. Preferably, representation of the documentpackage version number will be supported by this field. In oneembodiment, all of the documents in the Document Manifest will have theversion number associated with the last valid published version of thedocument package. Specifically, the version number is associated withthe package of documents rather than individual documents within thelisting. Thus, “Closing Package Version 1” will be initially published.If there is a later change to any single document within that packagefor which a new versioning is sought, then all of the documents in thepackage will be associated with “Closing Package Version 2”. When all ofthe documents are printed for publication, they will thus include thesame version number for the closing package, rather than having separateversion numbers belonging to each individual document. This allows easydetermination that the elements of the closing package are up-to-date.

Of course, although it is not necessarily recommended, there may beinstances where users elect not to print to the entire package forclosing package version 2. In that case, it is up to the user todetermine which documents did not change between the two versions.

For context, the illustrated process 1000 shows origination and closingphases. As described, origination is variously provided by conventionalsystems that are used to populate documents (1002). This may beaccommodated through an Automated Underwriting System (AUS) as indicatedor other conventional systems used for origination that need not bedescribed in detail herein.

Pursuant to a closing, at various times and for various purposes,parties may wish to view documents before the formal closing takesplace. For example a Lender, Closing Agent or Borrower might wish toreview data that is included on the documents to ensure accuracy, tomake changes that occur between the original population of the documentand the closing, etc. The “closing” process 1010 is divided into publish1020 and view 1060 components.

Notably, documents may be printed for review as part of the view 1060component. This is in contrast to publishing the documents, such as inanticipation of the formal closing. Printing 1062 the documents can beaccommodated from a selection list that is displayed in connection witha displayed document, or within the document if desired. Preferably,when the documents are printed 1062 during the view component 1060, theywill include indicia such as “DRAFT” in lieu of a version number, toclearly indicate that they are not a published version of the documents.

As described above, datasets that are used to produce documents areaccorded values useful in connection with receiving EQC requests andproducing corresponding EQC results and reports. Document publication isalso provided in conjunction with the EQC system functionality. Toaccommodate that, datasets (or even individual elements within datasets)may be accorded the values “System” and “Printed”. When drafts of thedocuments are printed for review, rather than published, thecorresponding dataset will remain denoted as “System”. The EQC systemfunctionality described above may thus be applied 1064 to a datasetmarked as System during the view 1060 phase of the closing process. Thisallows users to check data integrity and accuracy on the underlying(e.g., Closing Agent) dataset prior to requesting a publication of thedocuments.

Publication 1020 of the documents is accommodated in conjunction withthe other EQC system features. According to one aspect, the EQC systemdistinguishes datasets corresponding to published document sets fromthose that have not yet been published, by associating a “Printed” valuewith the former. As indicated, when publication 1020 is sought, thedocuments in a closing package are printed 1024. If necessary, thedataset corresponding to the printed documents is also uploaded to theEQC system, if it does not already reside therein Uploading may or maynot be necessary at this stage. This is because some users may use asystem that includes the EQC system functionality throughout the processof managing a transaction (e.g., from origination forward). In thatinstance the datasets will already reside on the EQC system. Other userswill invoke the EQC system at this stage, wherein the dataset may beuploaded in conjunction with publication. In either case, the EQC systemis used to check the accuracy and completeness of the data used toproduce the documents published for the closing package. As indicated,the EQC system functionality is applied 1026 to the correspondingdataset marked as “Printed”. Although the described embodiment uses theterm “Printed” in association with datasets corresponding to publisheddocuments, the artisan may substitute whatever terms are desired forthis indication, including but not limited to “Published”, etc.

As conceptually indicated in FIG. 10, versioning 1022 is associated withthe publication 1020 of documents. According to another aspect of thepresent invention, versioning is correlated with a set of documents usedfor a transaction, such as a closing package. The first publication ofthe closing package may be referred to as “Closing Package Version 1”.Preferably, each of the documents that is published as part of theclosing package is marked accordingly with this version number. Forexample, a footer for each document may state “CP v. 1” or the like.Accordingly, whenever a new publication 1020 request is made, the systemreviews the version counter 1022, and prompts an increment in theversion count to be associated with the set of documents being publishedin connection with the publication request. In embodiments that store aversion number as an element value, this may merely be incrementing thisvalue in association with publication.

If, following a publication, there is a realization that change isdesired in one or more of the documents, then values in the datasets maybe changed. In this instance, the user will presumably want to runanother EQC system check to ensure the accuracy and consistency of andamong datasets. This is done in conjunction with publication andversioning according to this embodiment of the present invention. First,the user makes the changes to the datasets. When these changes are made,the corresponding dataset and/or individual values are denoted asSystem, as they lose publication status as being different from thepublished version. At some point the user will again be satisfied withthe data, and will prompt publication. In this instance, “ClosingPackage Version 2” is established as the next version number for theclosing package. The previously described printing 1024 of the closingpackage documents, marking of the datasets as published, and application1026 of the EQC functionality to the datasets marked as published takeplace. Versioning is associated with the entire closing package. Thus,even if some of the documents remain exactly the same fromversion-to-version, they will be marked according to the most recentclosing package version in association with publication of the closingpackage. In other words, if version 2 of the closing package is printed,each document in the package is marked “CP v. 2” or the like.

In some embodiments, a formal electronic document, such as an XML orXHTML based document, may be used in conjunction with the documentmanifest and/or publication aspects of the present invention. In thatcase, a particular element for managing document publication may beestablished. The element is used to provide the listing of published(formally printed) documents prepared for use in a transaction such as aclosing. Preferably, this listing is accessed and used in conjunctionwith the above-described validation processes as part of managing thelist of documents to be provided for a closing package and ensuring thatthose documents are checked for accuracy and completeness. The elementfor managing document publication may be variously provided butpreferably includes attributes such as “name” for indicating the name ofeach document and “version_number” for managing the versioning ofdocuments. Other useful attributes may include a “filename” attributefor identifying a location of a file corresponding to a particulardocument, “date/time” for indicating a date/time stamp corresponding toa document version, “type” for indicating the document type,“pages_number” for indicating the number of pages in the document,“signature requirements” for indicating whether and how documents are tobe signed, and “comments” for indicating various associated comments orinstructions. The values of these attributes are useful for assemblingthe above described listing of documents for a package, along with therelated information, for the document manifest.

Although the present invention has been described in considerable detailwith reference to certain embodiments thereof, the invention may bevariously embodied without departing from the spirit or scope of theinvention. Therefore, the following claims should not be limited to thedescription of the embodiments contained herein in any way.

1-20. (canceled)
 21. A computer-implemented method, comprising:receiving, in connection with a mortgage loan that has not yet closed, aplurality of mortgage datasets from a plurality of parties associatedwith the mortgage loan; determining whether the mortgage loan, followingclosure, will satisfy a set of conditions for purchase of the mortgageloan in a secondary mortgage market, said determining comprisingautomatically applying quality control rules to the plurality ofmortgage datasets; and generating and outputting an indication ofwhether the mortgage loan, if closed based on the plurality of mortgagedatasets, will satisfy the set of conditions for purchase in thesecondary mortgage market; said method performed by execution of programcode by a computer system.
 22. The method of claim 21, wherein thequality control rules include investor-specific rules associated withmortgage purchase criteria of a particular investor.
 23. The method ofclaim 22, wherein the quality control rules additionally include corequality control rules that check for compliance with industry standardsgoverning sales of loans from lenders to investors.
 24. The method ofclaim 21, further comprising generating, for at least one of themortgage datasets, a seal that provides functionality for verifying thatno changes have been made to the mortgage dataset, said seal generatedusing a digital signature.
 25. The method of claim 21, wherein themethod comprises, by said computer system, generating a report thatindicates whether the plurality of mortgage datasets satisfy the qualitycontrol rules.
 26. The method of claim 21, further comprisinggenerating, by the computer system, a persistent record that indicates,following closing of the mortgage loan, whether the mortgage loanresulted from electronic mortgage data that complies with the set ofconditions for purchase in the secondary mortgage market.
 27. The methodof claim 21, wherein the quality control rules include rule setssubmitted to the computer system by each of a plurality of entities. 28.The method of claim 21, further comprising, by the computer system,reapplying the quality control rules to modified versions of themortgage datasets while tracking versions of the mortgage datasets. 29.The method of claim 21, wherein applying the quality control rulescomprises determining whether at least two of the plurality of mortgagedatasets are consistent with each other.
 30. The method of claim 21,further comprising, by the computer system, performing Extensible MarkupLanguage (XML) validation of the plurality of mortgage datasets beforeapplying the quality control rules.
 31. The method of claim 21, furthercomprising, by the computer system, using the plurality of mortgagedatasets, following application of the quality control rules, togenerate a set of loan documents for closing of the mortgage loan. 32.An electronic data quality control system, comprising: an electronicdata repository that stores at least one investor-specific rules setassociated with an investor, said investor-specific rules setcorresponding to loan purchase criteria applied by the investor toassess whether to purchase particular mortgage loans from lenders; and acomputer system programmed to apply at least the investor-specific rulesset to at least one electronic mortgage dataset of a mortgage loan thathas not yet closed to assess whether the mortgage loan will, afterclosing, satisfy said loan purchase criteria applied by the investor,said computer system further programmed to generate a report thatindicates whether the at least one electronic mortgage dataset complieswith the investor-specific rules set.
 33. The electronic data qualitycontrol system of claim 32, wherein the computer system is additionallyprogrammed to generate a persistent indication that specifies, followingclosing of said mortgage loan, whether the mortgage loan resulted fromelectronic mortgage data that complies with the lender-specific rulesset, the computer system thereby reducing a need to subsequently assesswhether the mortgage loan satisfies said loan purchase criteria.
 34. Theelectronic data quality control system of claim 32, wherein theelectronic data repository additionally includes, and the computersystem is additionally programmed to apply, a core rules set that isbased on industry standards governing sales of loans from lenders toinvestors, wherein the inventor-specific rules set specifies mortgageloan purchase criteria that extends beyond said industry standards. 35.The electronic data quality control system of claim 32, furthercomprising an interface for enabling participants to mortgagetransactions to submit rules sets to the electronic data repository forapplication by said computer system.
 36. The electronic data qualitycontrol system of claim 32, wherein the computer system is configured todetermine whether mortgage datasets of different parties to a mortgagetransaction are consistent with each other.
 37. The electronic dataquality control system of claim 32, wherein the computer system isadditionally programmed to perform version tracking of the at least onemortgage dataset, and to incorporate mortgage dataset versioninformation into said report.
 38. The electronic data quality controlsystem of claim 32, wherein the computer system is additionallyprogrammed to perform Extensible Markup Language (XML) validation of theat least one mortgage dataset before applying the investor-specificrules set.
 39. The electronic data quality control system of claim 32,wherein the computer system is additionally programmed to use the atleast one mortgage dataset to generate a set of loan documents forclosing of said mortgage loan.
 40. The electronic data quality controlsystem of claim 32, wherein the computer system is additionallyprogrammed to generate a closing document manifest that specifiesdocuments to be used for closing of the mortgage loan.
 41. A system,comprising: an electronic mortgage dataset stored in computer storage,said electronic mortgage dataset comprising data values for generating aset of closing documents for a mortgage loan, said electronic mortgagedataset further comprising a tamper-resistant seal for verifying that nochanges have been made to the electronic mortgage dataset sincegeneration of the seal; and a computer system programmed to apply a setof quality control rules to the electronic mortgage dataset to assesswhether the dataset is suitable for generating the set of closingdocuments.
 42. The system of claim 41, wherein the seal is based on adigital signature.
 43. The system of claim 41, wherein the computersystem is additionally programmed to generate the set of closingdocuments using the electronic mortgage dataset, and to generate aversion number that associates the set of closing documents with aparticular version of the electronic mortgage dataset.
 44. The system ofclaim 41, wherein at least some of the quality control rules correspondto conditions for a sale of the mortgage loan on a secondary market. 45.The system of claim 41, wherein at least some of the quality controlrules correspond to purchaser-specific purchase criteria applied by apurchaser of mortgage loans.